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Operating computers in space requires the use of very expensive radiation 
hardened microelectronics devices. Unfortunately, the United States radiation hardened 
market is rapidly shrinking and makes up a very small percentage of the commercial 
market. For these reasons, and the fact that commercial-off-the-shelf (COTS) devices 
are cheaper, more capable, readily available, and software availability is much greater, 
the use of COTS devices in future space systems is fast becoming a reality. A 
significant disadvantage of COTS devices is their susceptibility to radiation induced 
single event upsets (SEUs), among other radiation effects which are detnmental to 
electronic systems. 

This thesis focuses on the board level design of a tool which enables the analysis 
of fault tolerant computing techniques in a laboratory environment in the presence of 
radiation induced SEUs. When implemented, this tool will be beneficial to the study of 
using COTS devices in space. The tool will provide the capability to analyze the 
performance of hardware redundancy techniques and software algorithms intended to 
improve the performance of COTS microprocessors in this environment prior to their 
use in designs intended for actual space applications. Cadence Concept™ design 
schematics, associated Verilog® code and simulation results are presented to develop 
this concept. 
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I. 



INTRODUCTION 



A. BACKGROUND 

A fault tolerant system is one that can continue the 

correct performance of its specified tasks in the presence 

of hardware and/or software faults. Fault tolerance is the 

attribute that enables a system to achieve fault tolerant 

operation. In many sensitive applications fault tolerant 

computing techniques are employed where the failure of these 

systems could lead to disastrous results. Examples of such 

sensitive applications include aircraft and spacecraft 

flight control systems and power plant control systems. A 

recent example of such a failure occurred with the loss of 

PanAmSat's Galaxy 4 satellite. 

Galaxy 4's attitude control system and 
an identical backup unit conked out at 
approximately 6 p.m. Eastern Daylight 
Time May 19 [1998], sending the 

satellite into an uncontrolled spin. 

[Ref. 1] 

While the loss of this satellite was not necessarily 
"disastrous," it could indeed prove to be very expensive. 

The Galaxy 4 cost between $200 million and $250 million to 
build, launch, and insure. [Ref. 1] 

In the space environment there are three categories of 
radiation effects in integrated circuits. Total Dose 
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Effects, Dose Rate Effects, and Single Event Effects. 

Within Single Event Effects are the four sub-categories: 
Single Event Upset (SEU) , Single Event Latchup (SEL) , Single 
Event Gate Rupture (SEGR), and Single Event Burnout (SEB) . 
Total Dose Effects and Dose Rate Effects are destructive 
effects in integrated circuits arising from solar flares, 
neutrons from nuclear detonations, and protons in the Van 
Allen belts. In addition, three of the subcategories of 
single event effects (SEL, SEGR, and SEB) are also 
destructive. These effects must be compensated for with the 
use of radiation hardening and shielding techniques . On the 
other hand, SEUs, which are essentially bit flips occurring 
within a device due to ionized charge being collected in a 
circuit, can be reduced by hardware architecture and 
software techniques such as redundancy. 

Operating computers in the space environment requires 
the use of very expensive radiation hardened (rad-hard) 
devices. In addition to the use of rad-hard technology, 
space systems also employ many other approaches to fault 
tolerance such as hardware redundancy, fault tolerant 
software algorithms, error detecting/correcting codes, etc. 
While' deploying reliable, fault tolerant computers in space 
will always require rad-hard components, the number of 
suppliers of such devices is decreasing and the costs of the 
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devices continues to increase. Many manufacturers are 
abandoning their production of rad-hard devices in favor of 
the more lucrative, booming consumer electronics industry. 
According to the May 1997 issue of Military & Space 
Electronics , "U.S. Department of Defense (DOD) leaders are 

struggling to find new ways to safeguard the dwindling 
supplier base of radiation-hardened microelectronics that 
are necessary to meet future spacecraft requirements." [Ref. 
2] 

While the commercial satellite industry may fill the 
void, it is estimated that DOD must increase investments 
from $30 million per year to nearly $60 million per year to 
advance the technology and ensure a base of reliable 
suppliers. [Ref. 2] 

The issue is in the fabrication process of the 
microelectronic devices. The production of the unique rad- 
hard devices requires specialized processes and demand for 
them is considerably less than that for consumer 
electronics. With the costs of modern fabrication lines 
reaching nearly $2.8 billion apiece, it is obviously cost 
prohibitive for companies to merely have two separate 
production facilities: one for rad-hard devices and one for 

non-rad-hard devices . A company producing both rad-hard and 
non-rad-hard devices will have to give up precious 
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fabrication time to make a few devices for a limited market. 



This precious time takes away from the production of 
microelectronics for a booming PC market and could mean 
millions, if not billions, of dollars in lost revenue. 

Herein lies the fundamental economic reason for the 
escalating prices of rad-hard microelectronics. 

An approach to solving this problem, which is receiving 
considerable amount of research, is the development of new 
processes that allow companies to manufacture rad-hard 
devices without major changes to their fabrication process. 
Another possible approach is the development of alternative 
approaches in hardware and software fault tolerant design 
with non-rad-hard commercial-off-the-shelf (COTS) 
microelectronics to reduce the dependency on rad-hard 
technology. This research project addresses the latter 
approach . 

B . PURPOSE 

The goal of this research is to develop a fault 
tolerant computing testbed for use as a tool for the 
analysis of hardware and software fault handling techniques. 
In particular, the testbed is intended to allow the analysis 
of techniques to resolve faults caused by single event 
upsets. The testbed computer will employ a three CPU, 
triple modular redundant (TMR) , design. The TMR testbed 
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will allow flexibility in the hardware and software design 
enabling direct performance analysis of various approaches 
to fault tolerant design. The testbed will enable fault 
injection simulations and direct radiation testing on the 
system for data analysis and hardware/ software benchmarking. 

This project will help in the development of cheaper 
alternatives to the highly expensive radiation hardened 
devices. It will further the research of radiation testing 
and single-event upset research by providing a testbed for 
analysis of various hardware redundancy techniques as well 
as any software techniques chosen to be employed. The 
testbed will be used in direct radiation testing in a 
laboratory environment and/or placed in a satellite as an 
experimental payload to study the effects in the actual flux 
environment of the satellite. This study will benefit our 
development of small, economical satellites for both 
commercial and military use. 

C. THESIS ORGANIZATION 

The organization of this thesis largely follows the 
approach taken to the design of a TMR system. Chapter I is 
a brief introduction with background information. Chapter 
II describes the microprocessor selection process and the 
characteristics of the selected processor. Chapter III 
presents various topics in hardware redundancy including 
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triple modular redundancy, voting techniques, 
synchronization and timing issues. Chapter IV contains the 
actual hardware design of the testbed. Simulation and 
results are presented in Chapter V. Finally the 
conclusions drawn from this research are presented in 
Chapter VI. 
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II . PROCESSOR SELECTION 



A. CHARACTERISTICS 

The place to start when designing a computer is with 
processor selection. The selection of the processor, or 
processors in the case of hardware redundancy, is where 
critical decisions are made regarding expected operating 
environment, necessary performance, power consumption and 
space limitations. 

1. COTS vs. Rad-Hard 

In June 1994, a directive was issued by then Secretary 
of Defense William Perry requiring the use of COTS parts in 
military systems whenever possible. As previously 
discussed, the availability of rad-hard parts is diminishing 
and as a result military, NASA, and commercial spacecraft 
builders may eventually be forced to use COTS technology. 

There are significant advantages to using COTS devices. 
COTS devices tend to be state-of-the-art and are therefore 
significantly more capable than rad-hard devices. To put it 
in perspective, often the choice is between a COTS Pentium 
or a rad-hard 286 or 386 microprocessor. As an example, in 
July 1998 Space Electronics announced intentions to release 
a single-board computer for space designed with primarily 
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COTS devices. This product, running at 66 MHz, is intended 
to compete with the RAD6000 from Lockheed Martin Federal 
Systems, which runs at 33 MHz and costs twice as much. [Ref. 
3] The processor used in the new release product, the 6U 
VME SB486R radiation hardened 32-bit single board computer 
based on Intel's 80486 microprocessor, is still an order of 
magnitude slower than the 300-400 MHz microprocessors 
currently available for desktop PCs. 

Other advantages of COTS systems include lower cost and 
better availability. Often a rad-hard microprocessor can 
cost many (10-15) thousands of dollars more than more 
capable, current technology COTS devices. In addition, rad- 
hard devices often have uncertain delivery times . Because 
of the declining rad-hard device market, these devices often 
must be special ordered from a limited number of available 
manufacturers. On the other hand, manufacturers of COTS 
devices often have stockpiles and can deliver a product 
within 24-48 hours. Many powerful COTS devices can even be 
obtained over the counter at several big name electronics 
stores . 

Commercial software is much more available for COTS 
devices. Software development is a very costly part of 
building any computer system. As the complexity of 
microprocessors increases, so does the complexity of the 
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required software. If rad-hard devices are not identical to 
their COTS counterparts, software must be specially designed 
for this device. This is both expensive and time consuming. 
In addition, this specially designed software will have to 
undergo rigorous testing to check its response to unexpected 
situations. [Ref. 4] This is in contrast with software for 
COTS devices where large companies design software for these 
devices. The software becomes proven over time through the 
high volume of users and the consumers actually participate 
in the testing of these products. 

Finally, while not necessarily an advantage of COTS 
devices themselves, it is possible to achieve some degree of 
radiation hardness by employing various techniques to shield 
COTS devices which are not themselves radiation hardened. 
[Ref. 4] While the use of shielding has shown to improve 
the reliability of devices in radiation environments, it 
adds to the physical space and weight requirements . 

However, there are disadvantages to using COTS devices. 
While the reliability of COTS devices used in benign 
environments is known, their reliability in stressing 
environments (radiation, thermal, vibration) is uncertain. 
[Ref. 4] The susceptibility of COTS devices to radiation 
induced failures is a major concern, and survivability in 
the space environment may be difficult with many COTS 
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devices. While some COTS devices may have hardness levels 
of 100 kRADs or more, this hardness varies greatly from one 
device to another. This hardness varies even for devices 
produced by the same manufacturer. Because of this lack of 
hardness assurance by manufacturers, each individual device 
will have to undergo testing and effectively be space 
qualified . 

Another disadvantage of COTS devices is they change 
rapidly. The semiconductor industry generally cycles new 
technology every 6-18 months. The devices continue to get 
faster, more capable, and require less power. The advantage 
here is clear for devices intended for the normal, non- 
stressing environment. However, as the devices get smaller, 
faster, and more complex, they are becoming more susceptible 
to radiation. Finally, in many cases, the required safety 
and reliability specifications, especially for military 
applications, simply cannot be met by COTS devices. [Ref. 4] 

2. CISC vs. RISC 

Reduced instruction set computer (RISC) machines were 
designed to take advantage of the caching, prefetching, 
pipelining, and superscalar methods that were invented to 
improve the performance of complex instruction set computer 
(CISC) machines. The CISC machines depend on long complex 
instructions. The operand access for these instructions 
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required complex address arithmetic. As a result, CISC 
machines were unable to take full advantage of these 
techniques . 

The RISC focuses on reducing the number and complexity 
of instructions in the machine. This allows a reduction of 
actual machine hardware complexity. Early on, RISC machines 
operated such that each instruction completed in one clock 
cycle. This was achieved by limiting the instructions in 
RISC machines to a fixed length, usually 1 word. Thus, in a 
32-bit machine, one 32-bit word specifies everything there 
is to know about the instruction. 

With the advent of pipelining, the current goal is that 
(at least) one instruction will begin and (at least) one 
instruction will complete during every clock cycle. Since 
program execution time depends on throughput and not on 
individual instruction execution times, issuing (and thus 
completing) one instruction per clock cycle is an 
appropriate goal. This is achieved by making instructions 
simple, not by making the clock period longer. 

3. Size, Pinout, Power 

The size of the device determines the physical space 
required on the assembled board. Space and weight 
constraints are critical limitations imposed on systems for 
satellites and other space applications. Similarly, power 
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consumption is a critical factor in space applications where 
a steady, endless supply of power from a standard 120 volt 
outlet is not available. In applications where power comes 
from batteries and/or solar cells, available power is a 
precious commodity. 

The pinout of the device is often directly related to 
its physical size. In addition, many devices reduce their 
pinout requirements by having individual address and data 
lines multiplexed together on one interface pin. 

4. Bus width and Memory Size 

The bus width of COTS devices essentially follows 
current trends. While many processors are available today 
with 64-bit architectures, the RMD6000 microprocessor 
(considered to be the industry standard for radiation 
hardened microprocessors) incorporates a 32-bit 
architecture. Compared to 32-bit architectures, a 64-bit 
bus effectively doubles (design dependent) the pinout 
requirements and correspondingly increases the power 
consumption of the device. 

As bus size increases, the complexity of the 
interconnectivity hardware increases as well . Particularly 
in a TMR design where 3 microprocessors are connected 
together with voting hardware, increasing the bus width from 
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32- bits to 64-bits requires a rather significant increase in 
hardware and logic . 

The size of the physical memory that the processor can 
use is a significant factor in space applications as well. 

In space applications where large volume secondary storage 
media is generally not available, the bigger the physical 
memory potential the better. Of course, this is essentially 
limited by the bus architecture of the device. A device 
with a 64-bit bus can accommodate a larger physical memory 
space than a 32-bit bus device. Without large secondary 
storage media, all operations will be performed using ROM 
and RAM with varying combinations of ROM and RAM types 
depending on the application. Therefore, it is necessary 
that the available physical address (memory) space be large 
enough to accomplish the intended tasks . 

5 . Speed 

The speed of the device is an important issue. 

However, in a TMR design, the speed at which the system can 
operate will be limited by the propagation time of the 
voting and vote error control logic as well as the memory 
setup and hold times. Although new personal computers are 
currently available with processors running at 300-400 MHz, 
the current new radiation hardened microprocessors run at 

33- 66 MHz. 
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The speed of the microprocessor chosen for this TMR 
design will be limited by the critical path logic 
propagation time in the several FPGAs chosen to implement 
the voting and vote error control . 

6. Multiple Chip vs. Single Chip Implementations 

The tradeoff associated with a single chip processor 
versus a processor which requires additional hardware 
peripheral devices is a significant issue. This is 
especially true in a TMR design where each address/data line 
as well as each control line has to be voted to ensure 
agreement between the three processors. In addition, in 
space applications the potential for radiation induced error 
increases with each additional piece of hardware added. 

Other problems include fault localization. With 
microprocessors with external peripheral device 
requirements, voting and vote error control complexity is 
increased. Also, board reliability is inversely 
proportional to the number of chips on it. 

The overall complexity of the board design increases 
as well with microprocessors with external peripheral device 
requirements. In a TMR design, this increased complexity is 
compounded. In a single chip microprocessor, the associated 
interface complexity is internal to the device. Therefore 
radiation-induced faults are limited to a single device when 
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performing processor voting which corresponds to simpler 
voting logic and less hardware requirements . 

B. PROCESSOR REVIEW 

As part of this research, several microprocessors were 
analyzed based on the microprocessor characteristics 
discussed in the preceding section. Tables 1, 2, and 3 
contain data concerning the various COTS CISC and RISC 
microprocessors that were considered in developing the 
testbed . 

The processor chosen was the R3081 RISC Microcontroller 
manufactured by Integrated Device Technologies (IDT) . The 
reasons for this selection were many. From the outset of 
this research project, the intent was to choose a COTS 
device for the TMR design. 

The R3081 is a COTS, single chip, RISC architecture 
machine, with a 32-bit multiplexed address/data bus. The 
highly flexible and user configurable device can run between 
20 and 50 MHz and is readily available. 

The determining factor for selecting the R3081 was the 
availability of radiation environment performance data from 
the Naval Research Laboratory (NRL) . The R3081 was used in 
a triple vote experiment deployed on the Microelectronics 
and Photonics Testbed (MPTB) . The MPTB is a space 
experiment launched in 1997 into a high radiation orbit to 
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test performance, reliability, and survivability of new 
microelectronics and photonic devices operating in the space 
radiation environment. The triple vote experiment was one 
of 24 experiments onboard the MPTB which were individually 
scheduled by a core controller. The purpose of this 
experiment was to measure SEU, SEL, and Total Dose effects 
in IDT R3081 microprocessors vs. epi thickness. The three 
microprocessors used had epi thicknesses of 6, 8, and 12 
microns respectively. The MPTB design was obtained from NRL 
and used as a starting point for the testbed designed in 
this research project. 



Characteristic 


AM29000 


' AM29050 “ 


1 PowerPC 603e 


I Manufacturer 


AMD 


AMD 


1 IBM. Motorola 


Processor 
, Architecture 


Streamlined 

Instruction 


Streamlined 

Instruction 


RISC 


Package 


168-PQFP or 169- 
PGA 


169-PGA 




Floating Point 
Accelerator 


Y (off chip) 


y 


Y 


Memory Management 
Unit 


Y 


Y 


y 1 


Speed (MHz) 


16-33 


20-40 


200-250 


Integer 

1 Multiply/Divide 


Y 


N 


Y 


^ Bus Architecture 

1 


32-bit 3 bus 


3 2 -bit 3 bus 


Selectable 64-/32- 
bit data bus, 32- ; 

bit address bus 


Demultiplex Signal 


N/A 


N/A 


N/A 


' Physical Address 
t Space 








Power (watts) 


< 1 


< 1 


3.5 - 5.8 ' 


Single Chip 


N 


Y 


Y 


Built'in Master/Slave | 


1 Y 


Y 


Y 



Table 1. Microprocessor Review (1 of 3). 
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' Characteristic 


PowerPC 60 4 e 


1 PowerPC 750 


i R3081 1 


Manufacturer 


IBM. Motorola 


IBM, Motorola 


' IDT 


Processor 

Architecture 


RISC 


RISC 


MIPS/RISC 


Package 


255-CBGA 


360-CBGA 


^ 84 -pin MQUAD/PLCC | 


1 Floating Point 
Accelerator 


Y 




1 Y 

1 ' 


Memory Management 
Unit 


Y 


Y 


' 


, Speed (MHz) 


250-350 


200-300 


1 20-50 I 


Integer 

Multiply /Divide 


Y ' 

1 


Y (3) 


Y (2) 

j 


Bus Architecture 


64-bic data. 32- j 


32-bit data, 64- 


32-bit 


i _ 


bit address 


bit address 


address/data 

multiplexed 


' Demultiplex Signal 


N/A 1 


N/A 


Y 1 


Physical Address i j 

Space 1 1 


1 


4GE 


1 Power (watts) ^ 


6.0-14.5 1 


4,7-11,0 


2.375-4.125 


1 Single Chip ^ 


Y 


Y 


1 Y 1 


Built-in Master/Slave 


N IN 1 


N ! 



Table 2 . 



Microprocessor Review 
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j Characteristic 


' R36100 


1 R4650 1 


1 R5000 


' Manufacturer 


i IDT 


IDT 


IDT i 


Processor 
, Architecture 


MIPS/RISC 

1 


i MIPS-III/RISC 


MIPS-IV/RISC 1 


Pac)cage 


208 -pin MQUAD 

1 


288-pin MQUAD 


223-pin CPGA or j 

272-ball SBGA ; 


Floating Point 
Accelerator 


N 


Y 


Y 


Memory Management 
i Unit 


Y 

i 


Y 


Y 


' Speed (MHz) 


20-33 


100-180 


200 


Integer 

Multiply /Divide 


y 


Y 


Y 


Bus Architecture 


8-. 16-. 32-bit ' 


32- or 64-bit 


64-bit 


1 


programmable 


address/data 


address/data 




address and data i 


multiplexed 


multiplexed 


1 Demultiplex Signal 


N/A 1 


Y 


Y 


' Physical Address 
1 Space 


4GB 


4GB 




; Power (watts) 


2-3 


1.646-3.465 


7.59-8.25 


j Single Chip 


! Y j 


Y 


Y 


Built-in Master/Slave 


1 N 


N 


N 



Table 3 . 



Microprocessor Review (3 of 3) . 
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C. CHARACTERISTICS OF SELECTED PROCESSOR 

The IDT R30xx family of microprocessors is intended to 
offer the high-performance associated with the MIPS RISC 
architecture for low-cost, simplified, power sensitive 
applications. [Ref. 5] Some features of the R3081E include: 

• High level of integration minimizes cost 

• Over 40 MIPS at 50 MHz 

• Low cost 84-pin packaging 

• Large on-chip user configurable instruction and data 
caches 

• On chip Floating Point Accelerator (FPA) 

• 20 through 50 MHz operation 

• Multiplexed address/data bus interface with low 
cost, low speed memory systems with high speed CPU 
support 

• On-chip 4-deep write buffer eliminates memory write 
stalls 

• On-chip 4-deep read buffer supports burst or simple 
block reads 

Figure 1 shows a block diagram of the IDT R3081E 
microprocessor. Some of the highlights include: 

• System Control Coprocessor (CPO) 

Dedicated Exception/Control Registers 
Dedicated Memory Management Registers 

• Integer CPU Core 

32 32-bit general registers 

ALU, Shifter, Mult/Div Unit, Address Adder, and PC 
Control 

• Floating Point Coprocessor (CPI) 

16 64 bit registers 

Exponent, Add, Divide, and Multiply Units 
Floating Point Exception/Control 

• Configurable Instruction and Data Caches 

• 4-deep Read and Write Buffers 
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Address/ 

Data 



DMA Rd/VW SysCik Invalidate 

Control Control Control 



Figure 1 . 



IDT R3081 Block Diagram. 



From Ref . [ 5 ] . 
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1 . 



CPU Core 



The CPU Core is a full 32-bit RISC integer execution 
engine, capable of sustaining close to a single cycle per 
instruction rate. It contains a 5 stage pipeline and 32 
orthogonal 32-bit registers. [Ref. 5] 

2. System Control Co-Processor 

The integrated on-chip System Control Co-Processor 
(CPO) manages both the exception handling of the CPU and the 
virtual to physical address mapping. The fully associative 
64-entry Translation Lookaside Buffer (TLB) maps 4kB virtual 
pages into the physical address space. The virtual to 
physical mapping includes kernel segments which are hard- 
mapped to physical addresses, and kernel and user segments 
which the TLB maps 4kB page by 4kB page into anywhere in the 
4GB (potentially) physical address space. The TLB also 
allows 8 pages to be locked by the kernel to ensure 
deterministic response in real-time applications. [Ref. 5] 

3. Floating Point Co-Processor 

The R3081 also incorporates an integrated R3010A 
compatible FPA which is co-processor 1 (CPI) to the CPU. 

The high-performance co-processor provides separate add, 
multiply, and divide functional units for single and double 
precision floating point arithmetic. To the software 
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engineer, the FPA simply appears as an extension of the 
integer execution unit with 16 dedicated 64-bit floating 
point registers. The software references these as 32 32-bit 
registers when performing loads or stores. [Ref. 5] 

4 . Clock Generator Unit 

The on-chip clock generator manages the interaction of 
the CPU core, caches, and bus interface. It includes a 
clock doubler to provide a higher frequency signal to the 
internal execution core. [Ref. 5] 

5. Instruction and Data Caches 

The on-chip cache is default configured to 16kB 
Instruction Cache and 4kB Data Cache. However, the cache 
can be reconfigured by system software to 8kB of Instruction 
and 8kB of Data caches. The instruction cache is organized 
with a line size of 16 bytes (four 32-bit entries) which 
achieves hit rates in excess of 98% in most applications. 

The data cache is organized as a line size of 4 bytes (one 
word) and achieves hit rates near 95% in most applications. 
The high hit rates associated with the instruction and data 
cache contribute significantly to the performance of the 
R3081E. The instruction cache is a direct mapped cache 
capable of caching instructions from anyv/here in the 4GB 
physical address space. The instruction cache is 
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implemented using physical addresses and physical tags 
(rather than virtual addresses or tags) to eliminate the 
requirement of flushing on context switch. As with the 
instruction cache, the data cache is a direct mapped 
physical address cache capable of mapping any v;ord within 
the 4GB physical address space. However, the data cache is 
implemented as a write-through cache to insure that main 
memory is always consistent with cache memory. In order to 
minimize processor stalls due to data write operations, the 
bus interface utilizes a 4-deep write buffer which 
"captures" address and data information at the processor 
execution rate, allowing it to be written to main memory at 
the memory speeds with minimum impact to overall system 
performance. [Ref. 5] 

6 . Bus Interface Unit 

Because the R3081 uses its large internal caches to 
provide the majority of the bandwidth requirements of the 
execution engine, it can utilize a much simpler bus 
interface connection to slower memory. The bus interface 
utilizes a 32-bit address and data bus multiplexed onto a 
single set of pins. It also provides an ALE (Address Latch 
Enable) output signal to de-multiplex the A/D bus, and 
simple handshaking signals to process CPU read and write 
requests. The DMA Arbiter allows an external master to 
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control the external bus if desired. As described 
previously in the Instruction and Data Cache section, a 4- 
deep write buffer decouples the speed of the execution 
engine from the speed of the main memory system. The write 
buffers capture and FIFO processor address and data 
information in store operations and schedule them on the bus 
at a rate that can be handled by the system memory. The 
read interface is capable of both single word and quad word 
reads. Single word reads utilize a simple handshake, and 
quad word reads can utilize either a simple handshake or a 
tighter timing mode when the memory system can burst data at 
the processor clock rate. In order to accommodate slower 
quad word reads, the 4-deep read buffer FIFO is -utilized 
allowing the external interface to queue data within the 
processor before releasing it to perform a "burst" fill of 
the internal caches. [Ref. 5] 

7 . System Usage 

The bus interface of the IDT R30xx (including the 
R3081E) family was specifically designed to allow a wide 
range of memory systems. A typical system using off-the- 
shelf logic devices contains simple transparent latches to 
de-multiplex the R30xx address and data busses and the A/D 
bus; the data path between the memory system and the A/D bus 
is managed by octal transceivers; and a small set of PALs is 
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used to control the various data path elements, and to 
control the handshake between the memory and the processor. 
[Ref. 5] 



8. Instruction Set Architecture 

All instructions and addresses are 32 bits and the CPU 
utilizes a 5-stage pipeline to achieve a near one 
instruction per clock cycle execution rate. There are five 
basic groups of instructions; 

• Load/Store 

y Move data between memory and general registers 

• Computational 

Perform arithmetic, logical, and shift operations 
on values in registers 

• Jump and Branch 

Change control flow of program 

• Co-Processor 

Perform operations on the co-processor set 

• Special 

Movement of data between special and general 
registers, system calls, breakpoint operations 

Figure 2 displays the instruction formats of the R3081 

processor. Load/Store instructions are all encoded as 

Immediate, or I-Type, instructions. Computational 

instructions are encoded as either Register, or R-Type, 

instructions when both source operands and the result are 

general registers or I-Type when one of the source operands 

is a 16-bit immediate value. Jump and Branch instructions 

can be either J-Type (target address is PC + 26-bit 
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immediate value) , R-Type (target address is 32-bit value 
contained in one of general registers) , or I-Type (Branch 
Instructions where target address is formed from a 16-bit 
displacement relative to the PC) . Jump and Link 
instructions save a return address in register R31. Co- 
processor Loads and Stores are always I-Type. Special 
instructions are always encoded as R-Type. [Ref. 5] 



I-Type (Immediate) 
31 26 25 



21 20 16 15 



op 


rs 


ft 


immediate 


J-Type (Jump) 

31 26 25 0 


op 


target 



R-Type (Register) 

31 26 25 21 20 16 15 11 10 6 5 0 



op 


rs 


ft 


rd 


shamt 


funct 



where : 



op 


6-bit operation code 


rs 


5-bit source register specifier 


rt 


5-bit target register or branch condition 


immediate 


16-bit immediate, or branch or address displacement 


target 


2 6 -bit jump target address 


rd 


5-bit destination register specifier 


shamt 


5 -bit shift amount 


funct 


6-bit function field 



Figure 2. Instruction Formats. After Ref. [5]. 
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Table 4 lists the instruction set mnemonics of R3081E 
processor . 



9. The Pipeline Architecture 

The execution of a single instruction is performed in 
five separate steps: 

• Instruction Fetch (IF) 

Instruction virtual address translated to physical 
address and read from internal instruction cache 

• Read (RD) 

Instruction decoded and required operands read 

• ALU (ALU) 

Required operation is performed 

• Memory Access (MEM) 

If instruction was a Load or Store, the data cache 
is accessed 

• Write Back (WB) 

Results from ALU step updated in on-chip register 
file 

Figure 3 illustrates the pipeline and the capability to 
execute 5 instructions per cycle. Pipeline hazards in the 




Figure 3. 5-Instructions per Clock Cycle. After Ref. [5]. 
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R3081 are handled in both hardware and software. The 
hardware methods used are forwarding and stalling (minimal) . 
The hardware methods deal with instructions that need a 
result from the register file of the immediately prior 
instruction and in integer multiply and divide operations 
where an instruction attempts to access the LO or HI 
registers prior to completion of the multiply or divide. If 
this happens, the requesting instruction will be blocked 
until the result is ready. The software method used is an 
optimizing compiler and peephole scheduler of the assembler. 
Two instruction classes which use the software method are 
Load instructions and Jump and Branch instructions. Both of 
these instruction classes have a delay, or latency, of one 
cycle. Rather than include extensive pipeline control 
logic, the CPU gives responsibility for dealing with "delay 
slots" to software. The peephole optimizer, performed as a 
part of compilation or assembly, can reorder the code to 
insure that the instruction in the delay slot does not 
require the logical result of the "delayed" instruction. 

[Ref. 5] 

D. StJMMARY 

Having completed a review of some of the desired 
characteristics of a microprocessor to be investigated when 
designing a system, the IDT R3081 RISC microprocessor was 
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OP 


DESCRIPTION 


OP 


DESCRIPTION 




Load/Store Instzructions 




Multiply/Divido Instructions 


LB 


Load Byte 


MULT 


Multiply 


LBU 


Load Byte Unsigned 


MULTU 


Multiply Unsigned 


LH 


Load Halfword 


DIV 


Divide 


LHU 


Load Halfword Unsigned 


DIVU 


Divide Unsigned 


LW 


Load Word 




LWL 


Load Word Left 


MFHI 


Move From HI 


LWR 


Load Word Right 


MTHI 


Move To HI 


SB 


Store Byte 


MFLO 


Move From LO 


SH 


Store Halfword 


MTLO 


Move To LO 


SW 


Store Word 






SWL 


Store Word Left 




Jump and Branch Instructions 


SWR 


Store Word Right 


J 


Jump 






JAL 


Jump and Link 




Arithmetic Instructions 
(ALU Immediate) 


JR 


Jump to Register 


ADDI 


Add Immediate 


JALR 


Jump and Link Register 


ADDIU 


Add Immediate Unsigned 


BEQ 


Branch on Equal 


SLTI 


Set on Less Than Immediate 


BNE 


Branch on Not Equal 


SLTIU 


Set on Less Than Immediate Unsigned 


BLEZ 


Branch on Less Than or Equal to 
Zero 


ANDI 


AND Immediate 


BGTZ 


Branch on Greater Than Zero 


ORI 


OR Immediate 


BLTZ 


Branch on Less Than Zero 


XORI 


Exclusive OR Immediate 


BGEZ 


Branch on Greater Than or Equal to 
Zero 


LUI 


Load Upper Immediate 


BLTZAL 


Branch on Less Than Zero and Link 






BGEZAL 


Branch on Greater Than or Equal to 
Zero and Link 




Arithmetic Instructions 
(3-operand, register typo) 




Special Operations 


ADD 


Add 


SYSCALL 


System Call 


ADDU 


Add Unsigned 


BREAK 


Break 


SUB 


Subtract 






SUBU 


Subtract Unsigned 




Coprocessor Instructions 


SLT 


Set on Less Than 


LWCz 


Load Word from Coprocessor 


SLTU 


Set on Less Than Unsigned 


SWCz 


Store Word to Coprocessor 


AND 


AND 


MTCZ 


Move to Coprocessor 


OR 


OR 


MFCz 


Move from Coprocessor 


XOR 


Exclusive OR 


CTCz 


Move Control to Coprocessor 


NOR 


NOR 


CFCz , 


Move Control from Coprocessor 






COPz 


Coprocessor Operation 




Shift Instructions 


BCzT 


Branch on Coprocessor z True 


SLL 


. Shift Left Logical 


BCzF 


Branch on Coprocessor z False 


SRL 


Shift Right Logical 






SRA 


Shift Right Arithmetic 




System Control Coprocessor (CPO) 
Instructions 


SLLV 


Shift Left Logical Variable 


MTCO 


Move to CPO 


SRLV 


Shift Right Logical Variable 


MFCO 


Move from CPO 


SRAV 


Shift Right Arithmetic Variable 


TLBR 


Read Indexed TLB Entry 






TLBWI 


Write Indexed TLB Entry 






TLBWR 


Write Random TLB Entry 






TLBP 


Probe TLB for Matching Entry 






RFE 


Restore from Exception 



Table 4 



Instruction Mnemonics 



After Ref. 



[5] 




chosen. Although the performance of the R3081 is much less 
than that of the current microprocessors available, it does 
have the performance and computing power necessary for 
analyzing fault tolerant improvement techniques in the 
presence of radiation induced SEUs . In addition, the R3081 
has previously been tested by the Naval Research Laboratory 
and flown in actual space satellite experiments. Finally, 
the R3081 employs a flexible bus interface which makes it a 
good candidate for use in a redundant hardware design. 

In the next chapter, some of the concepts of triple 
modular redundancy, a hardware redundancy technique, are 
covered. This is followed by a description of a simple 
R3081 based system. Finally, a brief overview of how three 
R3081 processors were incorporated into a redundant design 
is presented. 
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III. HARDWARE REDUNDANCY 



There are many techniques available to achieve some 
degree of fault tolerance. Fault tolerant systems basically 
employ some combination of hardware, software, time, or 
information redundancy. The purpose of this chapter is to 
introduce the concept of triple modular redundancy (TMR) . 

The initial design of the testbed will employ a TMR design 
and as such TMR issues are dealt with thoroughly. The 
overall goal of this project is to design a testbed which 
allows flexibility in the ultimate methods employed to 
achieve fault tolerance. This will allow the user to 
compare and contrast the fault tolerant performance of many 
combinations of the different techniques. 

A. TRIPLE MODULAR REDUNDANCY (TMR) 

A common form of hardware redundancy is triple modular 
redundancy (TMR). The basic concept is fairly simple. It 
involves the triplication of the hardware and performing a 
majority vote to determine the output of the system. This 
technique is considered to be passive hardware redundancy in 
that it masks the occurrence of faults. Fault tolerance is 
achieved through the use of majority voting techniques 
without the need for fault detection or system recovery. 

[Ref. 6] If one of the modules becomes faulty, the two 
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remaining modules, which are fault-free, mask the fault when 
the majority vote is performed. In short, TMR uses three 
identical modules, performing identical operations, with a 
majority voter determining the output, as shown in Figure 4. 

In a TMR system with three microprocessors, an SEU 
could cause one processor to branch to a completely wrong 
address. That processor will continue to cause errors on 
all votes until it is reset to the state of the correct 
processors. Until it is reset, the system is no longer a 
TMR system. It is a dual processor with comparison system 
which provides for error detection but no error correction. 

One of the primary disadvantages with a TMR system is 
that the system can be no more reliable than the voter 
itself. Indeed the voter becomes a single point of failure— 
if the voter fails, the entire system fails. [Ref. 6] 

Several techniques can be used to overcome this. One method 
is the use of triplicated voters which produce three 
independent outputs. Here again three identical modules 
receive identical inputs and perform the same operations on 
those inputs. Each module provides its output to three 
separate and independent voters to produce the three 
results, as shown in Figure 5. Each output is correct as 
long as no more than one module, or input, is faulty. In 
essence, the voter is no longer the single point of failure. 
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A multi-stage TMR system can be built by 
interconnecting this triplicated voter approach as shown in 
Figure 6. [Ref. 6] A multi-stage system with triplicated 
voters can provide some error correction in that an error in 
a module of one stage is masked and the voters provide three 



Input 1 



Input 2 



Input 3 

Figure 4 . 




Triple Modular Redundancy. After Ref. [6] . 



Input 1 



Input 2 



Input 3 




Figure 5. TMR with triplicated voters. After Ref. [6]. 
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independent and "corrected" results to the next stage. At 
the final stage, the three independent outputs can then be 
voted again to form a single output. However, this final 
voter could again become the single point of failure. 



Input 1 



Input 2 



Input 3 




Figure 6. Multiple-stage TMR system. After Ref. [6]. 



A generalization of the TMR approach is N-Modular 
Redundancy (NMR) . [Ref. 6] TMR is based on the techniques 
of NMR. There are N redundant modules vice three. In 
general, N is chosen to be odd so that majority, voting 
techniques can still be applied. The advantage gained is 
that more module faults may be tolerated. In an NMR system 
with N redundant modules, majority voting will allow the 
system to tolerate faults in fN/2l - 1 modules. The 

primary concerns associated with NMR system deal with added 
logic hardware and circuit complexity. Clearly, one could 
design a system that continues to employ NMR voting at 
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multiple stages to improve system reliability. Referring to 
Figure 5, the triplicated voters could even be voted again 
to ensure faults are detected in the voters themselves. 

This could conceivably continue in an endless cycle. 
Practical applications and design constraints often prevail 
and are the limiting factor to choosing N in an NMR system. 
[Ref. 6] 



1. Voting Techniques 

Voting may occur at several locations within a system. 
Take, for example, a TMR system used as an industrial 
process controller. [Ref. 6] The controller could sample 
from three identical, independent sensors and perform a vote 
to determine which sensor value to use. This data is 
provided to three identical, independent modules to perform 
some calculations on the sensor data, and then a majority 
vote on these calculations is performed to perhaps adjust 
the controls of the process. The voting can be used on both 
analog and digital data. This approach masks and contains 
the effect of a faulty sensor. An alternative method might 
be to provide the values from each of the three sensors 
directly to a dedicated module, perform the necessary 
calculations, and then vote the results from the three 
modules. Here, faulty sensor data would be allowed to 
migrate into the processing modules. The tradeoffs between 
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the two approaches are slight but would obviously have to be 
analyzed to determine the appropriate design based on the 
application . 

A hardware voter is a relatively simple circuit to 
design and implement. All that is needed is a combinational 
logic circuit that produces a 1 when a majority of the input 
bits are 1 and a 0 when a majority of the input bits are 0. 
An implementation of a one-bit majority voter is shown in 
Figure 7 . Alternately, the carry out output of a 1-bit full 
adder will produce the necessary output to implement the 1- 
bit majority voter. An 8, 16, 32, or 64-bit voter can be 
constructed by replicating the circuit in Figure 7 in 




parallel for each bit that needs to be voted. One can see 
the amount of additional logic grows rapidly if, for 
instance, the three independent modules in a TMR system to 
be voted are 32 -bit microprocessors. The desired 
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reliability will certainly have to be weighed against the 
space, power, and weight limitations, especially in 
satellite and other space applications. 

2. Voting Issues 

In practical applications, timing will have to be 
considered when performing majority voting. If the three 
inputs to a majority voter arrive at different times, then 
depending on when the output of the voter is sampled, an 
incorrect vote may be generated. In many applications, an 
incorrect result cannot be allowed even for a very small 
period of time. [Ref. 6] There are techniques which can be 
applied that will force the inputs to the voter to be 
synchronized so that the output of the voter is sampled at 
the correct time. One approach to achieving synchronization 
involves a two-phase clock which drives master-slave D flip- 
flops on each input to the majority voter. The costs of 
using this synchronization approach will be in terms of 
additional logic and timing delays. 

Another problem that may be encountered in hardware 
voting is that the three modules in a TMR system, or the 
three sensors that feed the three modules, could disagree 
slightly even in a fault-free environment. These devices, 
sensors in particular, can seldom be produced so that they 
generate identical results under the same circumstances . In 
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addition, a single analog- to-digital converter can produce 
results that differ slightly in the least significant bits, 
even if the exact same signal is applied to it several 
different times. [Ref. 6] One technique used to get around 
this is to ignore a set number of the least significant bits 
generated. The assumption is that the result will differ in 
only a known number of the least significant bits. An 
alternative approach is the mid-value select technique. The 
voter basically just selects the middle value of the three 
inputs as shown in Figure 8. Essentially, it is the same 
concept as a majority voter but is necessary when the three 
values may have slight perturbations between them. The 
middle value is chosen 

Sensor 

Values 




Figure 8. Mid-value select technique. After Ref. [6]. 
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because an assumption is made that only one of the inputs 
can be faulty at one time. Thus, since minor perturbations 
are expected the middle value will always be one from a 
"good" input. The middle value is chosen instead of taking 
an average of the three inputs . This is because in the 
event that one input is clearly faulty as shown in Figure 8, 
the average would be adversely affected. In effect, the 
faulty input is ignored by selecting the middle value. 

Another problem that must be realized in a TMR system 
with majority voting is that identical errors in two of the 
modules will have to be tolerated. The errors will produce 
results that when passed to the voter will be selected as 
the majority. The possibility of this occurring and the 
consequences would definitely have to be investigated 
depending on the application. 

A significant danger of incorporating redundancy into a 
system is that the overall system reliability could be 
reduced, due to the increased number of components. If the 
redundant systems are not themselves reliable, there is 
little hope of improving the reliability of the system. 

[Ref. 7] For example, Wakerly notes that constructing a 
voting component for three microprocessors in a TMR 
structure could conceivably require 14 integrated circuit 
packages constructed from the same (unreliable) technology 
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as the three microprocessor packages, and hence would lead 
to a system with lower reliability than that of a single 
microprocessor chip. [Ref. 8] In addition, on a PC board, 
solder connections can be one of the largest sources of 
failure . 

On the other hand, given that the redundant components 
are sufficiently reliable and the additional logic required 
is at least as reliable as the redundant modules, TMR 
provides a viable technique for improving overall system 
reliability in critical applications. [Ref. 4] 

B. TRIPLE MODULAR REDUNDANT MICROPROCESSOR DESIGN 

Having reviewed the concepts of TMR, what follows is a 
description of how they might be employed with three 
microprocessors. Also, having chosen to build the Testbed 
using the IDT R3081 RISC Microprocessor discussed in 
Chapters I and II, it is useful to examine what is necessary 
in constructing a board with three R3081's operating in a 
TMR design. 

Figure 9 shows a block diagram of a simple system using 
a single R3081 processor. The multiplexed address/data bus 
of the R3081 is demultiplexed through the use of address 
latches and data buf f ers/transceivers . The address bus and 
the control bus are then used by the memory controller to 
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access the memory blocks. A typical design similar to 
Figure 9 is described in detail in Ref. [9] . 

Expounding on this simple system, Figure 10 shows a 
block diagram of a TMR system using three R3081 processors. 
Figure 10 shows the additional hardware blocks necessary to 
implement majority voting of the address, data, and control 




Figure 9. Simple R3081 Board Design. After Ref. [9]. 
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Figure 10. TMR R3081 Board Design. 



busses and how the voted busses are then used in the 
remainder of the system. 

A significant issue when using three microprocessors in 
a TMR design is the synchronization of the processors, 
briefly described in the preceding section. Voting Issues 
‘(Section A, Subsection 2, of this chapter) . The IDT R3081 
contains an output from the processor which is the System 
Reference Clock, SysClk* . This clock is used to control 
state transitions in the read buffer, write buffer, memory 
controller, and bus interface unit internal to the 
processor. As such it is used as timing reference by the 
external memory system. The frequency of this clock can be 
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either the same as the CPU cycle rate, or one-half that 
frequency. The frequency of this clock is selectable during 
the processor reset initialization. [Ref. 5] 

The R3081 does not have a guaranteed relationship 
between the input clock and the SysClk* System Reference 
Clock. However, it is possible to ensure the phase of this 
output reference clock allowing the multiple processors to 
be in the same phase. The IDT R3081 contains internal logic 
as part of its reset state machine, which forces the System 
Reference Clock, SysClk*, into a known state. [Ref. 5] Thus 
in a system using multiple R3081 processors with their 
System Reference Clocks operating at the same frequency as 
the CPU cycle rate, the negation of the Reset* input to the 
processors is sufficient to ensure that the System Reference 
Clocks from each processor are operating in the same phase. 
This assumes that the three processors are driven by the 
same input clock. [Ref. 5] If the Output Reference Clocks 
are operating at one-half of the frequency of the CPU cycle 
rate, additional steps are necessary to ensure 
synchronization between the System Reference Clocks from 
multiple CPUs. 

In order to take full advantage of the TMR design to 
allow error analysis, FIFOs dedicated to each processor were 
incorporated as shown in Figure 11. The FIFOs allow the 
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capturing of the address, control, and data bus information 
from each processor before it is passed to the majority 
voters as shown in Figure 10. 

Detailed descr^Lptions of the blocks shown in Figures 10 
and 11 and how they are implemented in the Testbed design 
are discussed in the next chapter. 




Figure 11. Testbed FIFO Interface. 
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IV. TMR TESTBED DESIGN 



A. OVERVIEW 

In order to observe the performance and behavior of a 
microprocessor in the presence of radiation induced single 
event upsets (SEUs), the address, data, and control busses 
must be monitored. This is because in a general purpose 
microprocessor there is not an efficient built-in mechanism 
to indicate to external devices and/or observers that an SEU 
induced error has occurred. This is particularly true in 
the case where one or more bits in a word of data are 
flipped. SEU induced errors may cause the processor to 
"lock up" or "crash, " which is detectable, but is of little 
use when trying to trouble-shoot and/or monitor the 
performance of the system. 

Monitoring of the address and data busses presents 
another problem. Without a separate entity which is deemed, 
or assumed, to be error free there is not a way to tell if 
the information that appears on the busses is error free or 
not. In addition, in the presence of radiation induced 
SEUs, the ability to correct such faults once detected is a 
desirable characteristic. 

In this testbed design, triple modular redundancy (TMR) 
was chosen to allow the monitoring of three identical 
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microprocessors running identical programs. The majority 
voting used in conjunction with TMR allows detection of an 
SEU which has been manifested as a disagreement between the 
address, data, and control busses of the three processors. 
The majority voter also allows the masking of these SEU 
induced disagreements. The address, data, and control bus 
information from the two microprocessors which are in 
agreement is used to start, control, and complete each bus 
cycle . 

This ass\ames that identical faults, or errors, will 
not occur in two different microprocessors and produce the 
same erroneous results on their associated busses. If this 
occurred, then the majority would be in an error state. The 
same argument applies for identical faults in all three 
processors. The following sections describe the Testbed TMR 
functionality and the use of dedicated FIFOs for error 
analysis . 



1. Testbed Operation Summary 

The testbed contains three IDT R3081 RISC 
microprocessors executing the same program and interrupt 
service routines. Each processor has a dedicated FIFO 
memory to capture the address, control, and data bus 
information during each bus cycle. The address, data, and 
control busses from the three processors are then combined 
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into single address, control, and data busses via majority 
voters. These voted busses are then used by a single 
memory/error cycle controller to access the same ROM and 
RAM. 



a. Normal (Error Free) Operation 

At the beginning of a bus cycle (Read, Burst Read, 
or Write), the address is latched from each processor's A/D 
bus . Voting commences on the address busses while they are 
simultaneously written to each FIFO. 

Control lines are next sampled from each processor. 
Voting commences on the control busses while they are 
simultaneously written to each FIFO. 

Data on the A/D bus from each processor is voted 
(during a Write cycle only) . Data on the A/D busses from 
each processor during both Read and Write bus cycles, 
including Burst Read, are written to each FIFO. 

If no error is detected (address, control, or data), 
then the current bus cycle finishes normally. 

b. Error Detection 

Errors are detected by majority voting of the 
address, control, and data busses from each processor. If 
an error is detected, the current bus cycle is allowed to 
complete before generating an interrupt. The error is 
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masked during Read and Write operations through the majority 
voter. However, the address, control, and data bus 
information associated with each processor before voting 
occurs will have been placed in each FIFO for analysis. 

Upon completion of the current cycle, an interrupt is 
generated and synchronously supplied to each processor. 

c. Error Correction 

Upon receipt of an interrupt, each processor 
executes the same interrupt service routine. The beginning 
of this routine is signaled by initiating a write to "dummy" 
address IFSOxxxxh- The dummy address is recognized by the 
address decoder and a dedicated chip select is asserted. 

This chip select is in turn recognized by the memory/error 
cycle controller. The memory/error cycle controller clears 
the current interrupt and disables subsequent vote error 
interrupts while the interrupt routine executes . 

The internal general purpose registers, configuration 
registers, and instruction and data caches are written to a 
reserved location in RAM. While this occurs, all internal 
information associated with each processor is written to a 
dedicated FIFO. The majority voter masks the error in the 
faulty processor and the "corrected" information, based on 
the majority of the two agreeing processors, is written to 
RAM. All internal registers and caches in each processor 
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are then filled by reading the reserved locations in RAM. 

The "faulty" processor will now have been "corrected" and 
re- synchronized with the other two processors. 

The processors signal the end of the interrupt service 
routine by initiating another write to "dumimy" address 
IFSOxxxxh. The memory/ error cycle controller will then re- 
enable vote error interrupts, and the next bus cycle begins. 

d. Error Monitoring 

The operation of the Testbed is monitored via an 
outside interface system. This outside system reads the 
contents of the FIFOs associated with each processor. 
Address, control, and data bus information from each 
processor are placed in FIFOs during non-error bus cycles. 

Upon detection of an error and interrupt handler 
execution, all internal registers and caches for each 
processor are written to the dedicated FIFOs. 

The FIFOs now contain the information necessary to 
detect which processor was in error and what the processors 
were doing at the time the error occurred. 

2. IDT R3081 Simulation 

We do not have a model of the complete R3081 RISC 
Microprocessor for simulation of the Testbed design. 
Therefore, in order to develop the concept of this design we 
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modeled the behavior of the IDT R3081 multiplexed 
address/data bus and associated control lines using the 
Verilog Hardware Description Language [Ref. 10]. The 
remaining sections of this chapter describe in detail each 
of the blocks in the Testbed design. 

In the descriptions of the blocks and in the associated 
figures, the following convention has been used. Signal and 
bus names which are bold and italicized, FORCE_A for 
example, are intended to match the same signal and bus names 
in the overall schematic in Appendix A for ease in cross 
referencing. In addition, signal and bus names which begin 
with an underscore, _ALE for example, represent signals 
which come from each of the three processors. Thus _ALE 
represents A_ALE, B_ALE, and C_ALE, for example. 

B. IDT R3081 BUS INTERFACE 

In this section, we will demonstrate that the bus 
interface simulation matches the manufacturers design 
specifications for the R3081. 

The datasheet for the IDT R3081 RISC Microprocessor 
[Ref. 11] was used in conjunction with the R3081 Hardware 
Users Manual [Ref. 5] . The single datum (word or byte) 

Read, Burst Read, and Write bus cycle timing diagrams and 
timing parameters were analyzed and used to simulate the 
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R3081 bus interface. Figures 12, 13, and 14 are the bus 
cycles obtained from these references. 
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Figure 12. IDT R0381 Burst Read Cycle. From Ref. [9] 
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Figure 13. IDT R3081 Write Cycle. From Ref. [9]. 




Figure 14. IDT R3 081 Single Datum Read. From Ref. [9] 
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The Diag(l) and Diag(O) signals shown in Figures 12, 13, and 



14 were not modeled. These two pins are useful in the 
initial debug of R30xx family based systems. [Ref. 5] 
Although they are not control lines, in an actual 
implementation of the Testbed, these lines could easily be 
added as part of the control bus from each microprocessor 
and passed to the control majority voter. They are not 
needed to control the bus/memory interface. However, they 
could be used as additional status lines to detect 
differences among the three processors. 

Figure 15 shows the R3081 bus interface simulator built 
in Cadence Concept™ Schematics and the Verilog Hardware 

Description Language. The associated Verilog code is 
contained in Appendix C, Section A. The three pins on the 
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Figure 15. IDT R3081 Bus Interface Simulator. 
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simulator labeled TRANS<2..0>, ADDR<31..0>, and DATA<31..0> 



are not pins on an actual R3081 device. These pins are 
used during simulations to force the simulator to execute a 
specified bus cycle. TRANS<2..0> is used to specify either 
Byte Read, Word Read, Burst Read, Byte Write, or Word Write 
bus cycles. ADDR<31. ,0> is used to specify the address of 
the current bus cycle. If the current bus cycle specified 
is a Burst Read, then ADDR<31..0> specifies the initial word 
address. DATA<31,.0> is used to specify the data to be used 
during Write bus cycles. By using three separate simulators 
and specifying each of the above three signals separately to 
each simulator, faults can be injected into the system. 

Figures 16, 17, and 18 show the simulated address/data 

bus and control line behavior. Extra wait states; i.e., 
additional system reference clock cycles, have been added to 
each bus cycle. The extra wait states allow FIFO memories 
dedicated to each microprocessor to grab the address, 
control, and data bus information. In addition, in these 
three figures the address /data bus and control lines from 
each of the three microprocessors are displayed to show they 
are synchronized with one another. 

In Figure 16, the Burst Read cycle is initiated at the 
falling edge of the _RD* and _BURST* lines from each 
microprocessor. In this particular example, the address 
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IFCOOOOOh is placed on the multiplexed address/data bus, 
_AD<31. ,0>, by each processor. After this address is 
latched using the _ALE signals from each processor, the 
first word of data appears on the _AD<31.,0> bus after a 
short delay from the memory. The four contiguous words of 
memory read during this bus cycle are obtained by providing 
the initial address, IFCOOOOOh in this case, and strobing 
the _ABDR3 and _ADDR2 lines so that they count in binary 00, 
01, 10, and 11. In addition, the memory controller strobes 
the RDCEN* line, which is supplied to all three 
microprocessors, four times indicating when the expected 
word from memory has been placed on the bus . The burst read 
cycle is completed at the rising edge of the _RD* and 
_BURST* signals. In the example in Figure 16 the four 
addresses read are IFCOOOOOh, 1FC00004h, 1FC00008h< and 
IFCOOOOCh. In this design, the addresses IFCOOOOOh through 
IFCOxxxxh are decoded to be read only memory (ROM) . The 
four words read contained the data OOOOOOOOh/ OOOOOOOIh, 
00000002k, and 00000003 h, respectively. This correctly 
corresponds to the data which has been programmed into the 
EPROM. See Appendix C, Section I. 

In Figure 17, the Write cycle is initiated at the 
falling edge of the _WR* lines from each microprocessor. 
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Figure 16. 



Simulated R3081 Burst Read Cycle 
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In this particular example, the address OOOOOOOOh is placed 
on the multiplexed address/data bus, _AD<31..0>, by each 
processor. After this address is latched using the _ALE 
signals from each processor, the data to be written appears 
on the bus. In this example, the data to be written is 
IIIIIIIIh. The ACK* signal, which is returned from the 
memory controller, indicates the write has been completed. 
The write cycle is completed at the rising edge of the _WR* 
signal. In the TMR Testbed design, addresses OOOOOOOOh 
through OOOVFFFFh correspond to random access memory 
(RAM) . Therefore, in this example, IIIIIIIIh has been 
written to RAM at address OOOOOOOOh- 

In Figure 18, the single datum Word Read cycle is 
initiated at the falling edge of the _RD* lines from each 
microprocessor. In this particular example, the address 
OOOOOOOOh is placed on the multiplexed address/data bus, 
_AD<31. .0>f by each processor. After this address is 
latched using the _ALE signals from each processor, the data 
appears on the bus after some delay. The RDCEN* line from 
the memory controller indicates that the address/data bus 
contains valid data. The read cycle is completed at the 
rising edge of the _RD* lines. In this example, IIIIIIIIh 
has been read from RAM at address OOOOOOOOh- This correctly 
corresponds with the IIIIIIIIh written to address OOOOOOOOh 
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Figure 17 



Simulated R3081 Write Cycle 
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Figure 18. Simulated R3081 Read Cycle. 
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in the previous example Write cycle description and in 
Figure 17 . 

C. ADDRESS/DATA BUS DEMULTIPLEXING 

The multiplexed 32-bit address/data bus of each of the 
three microprocessors is demultiplexed using the address 
latch enable, _ALE, signal [Ref. 5] from each processor. 

The schematic diagram of the demultiplexer is contained in 
Appendix B, Section A. Figure 19 is a block diagram of the 
demultiplexer . 



32-bit Address/ 
Data Bus 
{_AD<31.,0>) 



32-bit Data Bus 



R3081 

RISC 

CPU 



Address Latch 
Enable UALBj 



Address/Data Bus 
Demultiplexer 



32-bit Address Bus 



TESTENV 



Figure 19. Address/Data Bus Demultiplexing. 

Each 32-bit demultiplexer makes use of four 8-bit 
FCT373 transparent latches. [Ref. 9] During each bus cycle 
(Read, Burst Read, or Write) the address is placed on the 
_AD<31. ,0> bus of each processor at the beginning of the 
cycle. While the _ALE signals are HIGH, the transparent 
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latches allow the address information to pass to the 32-bit 
address voter. This allows the address information to be 
voted and passed to the memory/ address decoder as soon as it 
becomes available. When the _ALE signals transition from 
HIGH to LOW, the address information is latched to the 
associated 32-bit address bus. Subsequent changes on the 
_AD<31..0> busses do not affect the state of the address 
busses until the next _ALE transition from LOW to HIGH, 
which occurs during the next bus cycle. The TESTENl* line, 
which is supplied to each demultiplexer, can be used to 
place the address bus, or output of each demultiplexer, in a 
high impedance state for testing. During normal operations, 
the TESTENl* line should be held LOW. The schematic diagram 
of the three microprocessors, the demultiplexers, and the 
associated connections is contained in Appendix A. 

D. DATA BUS VOTING 

The _AD<31..0> bus from each microprocessor is 
considered to be the data bus after the transition of the 
ALE signal from HIGH to LOW during each bus cycle. The 32- 
bit data busses from each processor are passed to a 32-bit 
majority voter /transceiver . Figure 20 is a block diagram of 
the data bus voter/ transceiver . 
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During a Write cycle, the three 32-bit data busses are 
voted to produce a single 32-bit data bus. However, during 
a Read, or Burst Read, bus cycle the data read from memory 
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Figure 20. Data Bus Voting. 

must be allowed to pass back to the three _AD<31..0> busses 
and on to the three microprocessors. This is accomplished 
via the RDDATAEN* and WRDATAEN* control lines from the 
memory enable controller. While the NRDATAEN* signal is 
LOW, the three data busses are voted and passed to the 
single data bus. While the RDDATAEN* line is LOW, the data 
on the single bus which has been read from memory is allowed 
to pass back through to the three microprocessors . Voting 
of the data busses occurs only during a Write cycle and when 
WRDATAEN* is LOW. The WRDATEN* and RDDATAEN* signals are 
mutually exclusive (when one is HIGH, the other is LOW) . If 
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an error is detected on one of the data busses supplied to 
the voter, the signal DATAERR goes HIGH. 

In addition, the majority voter/ transceiver uses three 
input lines {FORCE_A, FORCE_B, and FORCE_C) which, when 
pulled HIGH, force the data from the respective bus through 
to the output data bus. When one of these signals is pulled 
HIGH, voting errors are not detected or signaled. These 
signals should all be held LOW during normal operations. 

The schematic for the 32-bit majority voter /transceiver 
and associated Verilog code are contained in Appendix C, 
Section B. 

E. ADDRESS BUS VOTING 

The output of the three demultiplexers is considered to 
be the address bus associated with each processor. Once a 
bus cycle has initiated and the _ALE has transitioned from 
HIGH to LOW, the address bus holds the address information 
until the LOW to HIGH transition of _ALE during the next bus 
cycle. The address bus from each demultiplexer is passed to 
a 32-bit majority voter. This majority voter operates 
similarly to that of the majority voter/ transceiver 
described in the previous section except there is no 
associated transceiver operation or control lines. Figure 
21 is a block diagram of the address voter. If an error is 
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detected on one of the address busses supplied to the voter, 



the signal ADDRERR goes HIGH. 
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Figure 21. Address Bus Voting. 

The schematic for the 32-bit majority voter and 
associated Verilog code are contained in Appendix C, Section 

D. 



F. CONTROL BUS VOTING 

Six control lines from each of the three processors are 
voted using an 8-bit majority voter. The six control lines 
voted are _ADDR2, _ADDR3, _RD* , _WR*, _BURST*^ and _DATAEN* . 
The other two inputs to the 8 -bit voter are not used and are 
held LOW. These control lines are voted to produce a single 
control bus. Figure 22 is a block diagram of the control 
bus voter. This majority voter operates similarly to that 
of the majority voter /transceiver described in Section D 
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except there is no associated transceiver operation or 
control lines. If an error is detected on one of the 
control lines supplied to the voter, the signal CONTERR goes 
HIGH. 
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Figure 22. Control Bus Voting. 

The schematic for the 8-bit majority voter and 
associated Verilog code are contained in Appendix C, Section 

C. 



G. ADDRESS DECODER 

The address decoder uses the voted address bus, 
VOTEADDR<31 . . 17> , to generate chip selects. The address 
decoder does not wait for _ALE to begin generating the chip 
selects. This is done to achieve better performance since 
the chip select outputs will be generated earlier in the bus 
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cycle. As a side effect, however, the chip select outputs 
may tend to "glitch" as a valid address is driven. Thus, 
the Read Enables and Write Enables seen in the memory system 
must be synchronized so they are valid only when the CPUs 
are attempting a read or write transfer. This combination 
allows maximum performance because address and chip selects 
are seen early in the bus cycle but the Read and Write 
signals are synchronized to ensure proper system operation. 
[Ref. 9] Figure 23 is a block diagram of the address 
decoder . 
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Figure 23. Address Decoder. 

The schematic for the memory /address decoder and 
associated Verilog code are contained in Appendix C, Section 
E. 
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H. 



MEMORY /ERROR CYCLE CONTROLLER 



The memory cycle controller provides a wait-state 
generator which stalls the bus interfaces of the three 
processors so that various types and speeds of memories can 
be used. [Ref. 9] This also allows the additional wait- 
states required for the FIFO interface described later. 
Figure 24 is a block diagram of the memory/error cycle 
controller. The memory/error cycle controller is composed 
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Figure 24. Memory/Error Cycle Controller. 

of three subsections. The basic RAM/ROM subsection 
generates the appropriate timing signals such as ACK* , 
RDCEN*, and BUSERROR* for operating the R3081 bus interface 
as well as the necessary write and read enables for 
accessing the RAM/ROM. The FIFO memory cycle controller 
generates the signals necessary for capturing the state of 
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each processor in its dedicated FIFO at the appropriate 
times during each cycle. The error cycle controller 
monitors the vote error signals from the address, data, and 
control bus majority voters. If an error is detected, it 
generates an interrupt to the processors. It also disables 
the vote error interrupts while the interrupt handler 
routine is executed by the processors. The schematics for 
the memory/error cycle and memory enable controllers and 
associated Verilog code are contained in Appendix C, 

Sections F and G. 

1. RAM/ROM Cycle Controller 

The basic state machine looks for the start of a read 
or write bus cycle by looking for a negative edge of VOTED* 
or VOTWR* from the control bus majority voter. When a bus 
cycle is initiated, the state machine starts a 5-bit up 
counter, counter<4 . . 0> . The counter then increments on each 
SYSCLK* rising edge. This counter is then used as the 
timing master for all other control signals generated by the 
state machine. [Ref. 9] 

A synchronous decoder, CYCEND* , is used to tell the 
counter when the end of a memory cycle occurs. CYCEND* is 
used to synchronously reset the state machine when a 
positive edge of VOTED* or VOTWE* is expected. Another 
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output, ENSTART* , is used to start the byte enables 
generated by the memory enable controller. [Ref. 9] 

Other outputs from the memory cycle controller include 
cycle termination inputs RDCEN* , ACK* , and BUSERROR* . On a 
read transfer, VOTBURST* from the control bus voter and the 
current active chip select from the address decoder are used 
to determine the timing and quantity of RDCEN* signals to be 
asserted. ACK* is asserted at the end of a write cycle to 
indicate completion of the transfer. BUSERROR* is used to 
end an undecoded memory cycle. [Ref. 9] 

2 . FIFO Memory Cycle Controller 

In order to provide the ability to observe the status 
of each processor before, during, and after an error cycle, 
the address, control, and data busses (before the majority 
voters) from each processor are written to a dedicated FIFO 
memory. The state machine in the memory cycle controller is 
used to generate the outputs ADDRTOFIFO* , CONTTOFIFO* , 
DATATOFIFO* , and FIFOWE* . Figure 25 shows a block diagram 
of the FIFO dedicated to processor A. A similar arrangement 
is used for the FIFOs dedicated to processors B and C. The 
use of the memory cycle state machine ensures the timing of 
these signals are synchronized with the current bus cycle 
and that during a Burst Read bus operation, the address. 
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control, and data busses are written to the FIFOs four 
times . 




Figure 25. FIFO Controls. 

The ADDRTOFIFO*, CONTTOFIFO* , and DATATOFIFO* outputs 
synchronously select when to provide the address bus, 
control bus, and data bus respectively to the FIFO 
associated with each processor. Since the address is the 
first bus to stabilize, ADDRTOFIFO* is asserted first. This 
is followed by CONTTOFIFO* and then DATATOFIFO* . FIFOWE* is 
the actual write enable supplied to the three FIFOs. 

When ADDRTOFIFO* is asserted, the address bus from each 
processor is supplied to its associated FIFO and written at 
the rising edge of FIFOWE*. This is followed by CONTTOFIFO* 
and DATATOFIFO* , in turn. 
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Figures 26, 27, and 28 show the operation of these FIFO 
controls during a Burst Read, Write, and single word Read 
respectively . 

3. Error Cycle Controller 

The memory cycle controller state machine also controls 
the generation of an interrupt which is supplied to each 
processor at the detection of a vote error (ADDRERR, 

CONTERR, or DATAERR) . 

The vote error interrupt, VOTERRINT* , is generated only 
at the end of the current bus cycle. This allows the 
current bus cycle to complete, with the majority voters 
masking the associated fault. In addition, allowing the bus 
cycle to complete ensures the FIFOs associated with each 
processor capture the state of the address, control, and 
data bus of each processor prior to generating an interrupt. 

It is intended that the three processors will 
synchronously receive the interrupt, and will execute the 
same interrupt service routine. The beginning and end of 
this service routine is indicated by a write to "dummy" 
address IFSOxxxxh. This address is decoded by the memory 
decoder to generate the chip select INTCS* . The error cycle 
controller, upon detection of a write cycle with this chip 
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Figure 26. 



FIFO Controls During Burst Read Cycle. 
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Figure 27. 



FIFO Controls 



During Write Cycle. 
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<Start Tiific>/|<Start Ti»e>, <End Tine>|> PAN RIGHT ; 

<Start Tijfle>/j< Start TiinO, <End Tiine>j> PAN RIGHT ; 

<Start Tijne>/j<Start Tine>, <Bfid Tune>j> 3.8usecs,4.3usecs 
<Start Time >/ i < Start Tiitie>, <Ehd Tiwe>i> | 





Figure 28 



FIFO Controls During Read Cycle 



select asserted, clears the interrupt and disables 
further vote error interrupts. The interrupt is disabled 
until the end of the interrupt routine. This is again 
signaled by the next write to "duirimy" address IFSOxxxxh. 

During the interrupt routine, it is intended that the 
processors will write all of their internal general purpose 
registers, configuration registers, and instruction and data 
caches to some selected portion of RAM. The vote error 
interrupt will have been disabled. However, errors in the 
"faulty" processor will be masked by the majority voted 
output from the other two "agreeing" processors during each 
write. Then, the interrupt routine would read back the 
selected portion of RAM and refill all of its internal 
general purpose registers, configuration registers, and 
instruction and data caches. Thus, the processor which had 
an error will have been corrected and re- synchronized with 
the other two processors. While this routine is executing, 
the FIFOs associated with each processor will capture all of 
the internal information of each processor for error 
analysis . 

The IDT R3081 Microprocessor Bus Interface Simulator 
module contained in Appendix A, Section A, contains a 
simulated, abbreviated interrupt service routine which 
executes when the interrupt INT5* is asserted. Simulations 
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which show the operation of the error cycle and this 
simulated interrupt service routine are contained in Chapter 

V. 

I . SYSTEM INTERFACE 

The system interface is intended to be a laptop or 
similar system which can read the FIFOs associated with each 
microprocessor and perform some analysis. This provides for 
both real-time and post error analysis. The FIFOs selected 
allow for asynchronous writing and reading with separate 
write and read clocks which can be different frequencies. 
Figure 29 is a block diagram of the system interface. 



EF_A2' 



From 
FIFO^ 

^ I F1FOAOUT<31..0:^ 



From 

FIFo[ 

® I 

From 

FIFO^ 



FIFOB0UT<31..0:^ 



EF_C2* 



C FIFOCOUT<31..0:^ 



System 

Interface 



A_OE* 



B_OE' C_0£* 



i i 



i 



RDCLK 



FIFORD' 



Output Enables and Read Enables to FIFOs 



Figure 29. System Interface. 

The testbed interface monitors the FIFO empty lines 
from processor A' s FIFO, EF_A1* and EF_A2* . As soon as they 
are both deasserted, the interface reads the FIFO. This is 



76 



followed by monitoring the FIFO empty lines from processor 
B's FIFO, EF_B1* and EF_B2*, and reading processor B's FIFO 
once they are both deasserted. Finally, the FIFO empty 
lines from processor C's FIFO, EF_C1* and EF_C2*, are 
monitored and the FIFO is read once they are both 
deasserted. This process continues and the address, 
control, and data information stored in the associated FIFOs 
are obtained by the interface. The read clock is set to be 
twice the frequency of the write clock. This enables the 
interface to read the data out of the FIFOs fast enough so 
they never fill up. Figure 30 shows the timing of the 
control signals generated by the system interface. 

The interface module writes the results obtained from 
the FIFOs to a text file, TMR_trace . out . By reviewing this 
text file, the status of the processors during each bus 
cycle can be observed. Examples of this text file obtained 
during both normal (error free) and induced error operations 
are contained in Chapter V. 

The schematics for the system interface and associated 
Verilog code are contained in Appendix C, Section J. 
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Figure 30. 



System Interface Controls. 
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V. 



SIMULATION RESULTS 



The complete design has been implemented in Cadence 
Concept™ schematics and the Verilog® Hardware Description 

Language. Timing parameters have been obtained from actual 
device datasheets. The IDT R3081 bus /memory interface in 
this TMR design can be simulated in Cadence Logic 
Workbench™ to verify the concept of operation and test the 

voting logic, memory and error cycle controllers, as well as 
the FIFO interface. 

The following simulation results were obtained from the 
trace file generated by the simulated system interface. The 
information displayed represents what was actually read from 
each FIFO. 

The overall testbed schematics are contained in 
Appendix A. The Cadence supplied modules and user defined 
modules used in the schematics and the simulations are 
contained in Appendices B and C, respectively. The script 
control language (SCL) files which were used to drive the 
inputs to the Testbed schematics to obtain the following 
simulation results are contained in Appendix D. 
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A 



NORMAL (ERROR FREE) RESULTS 



Bus cycles 1 through 4 correspond to a Burst Read from 
EPROM addresses IFCOOOOOh through IFCOOOOCh. The data read 
corresponds to the data programmed into the Verilog EPROM 
module in Appendix C, Section I. 





CPU A 


CPU B 


CPU c 


Address = 


IfcOOOOO 


IfcOOOOO 


IfcOOOOO 


Control = 


00000008 


00000008 


00000008 


Data = 
A Control 
B Control 
C Control 


00000000 
= Burst Read 
= Burst Read 
= Burst Read 


00000000 
Word 0 
Word 0 
Word 0 


00000000 


Address = 


IfcOOOOO 


IfcOOOOO 


IfcOOOOO 


Control = 


00000009 


00000009 


00000009 


Data = 
A Control 
B Control 
C Control 


00000001 
= Burst Read 
= Burst Read 
= Burst Read 


00000001 
Word 1 
Word 1 
Word 1 


00000001 


Address = 


IfcOOOOO 


IfcOOOOO 


IfcOOOOO 


Control - 


0000000a 


0000000a 


0000000a 


Data = 
A Control 
B Control 
C Control 


00000002 
= Burst Read 
= Burst Read 
= Burst Read 


00000002 
Word 2 
Word 2 
Word 2 


00000002 


Address = 


IfcOOOOO 


IfcOOOOO 


IfcOOOOO 


Control = 


0000000b 


0000000b 


0000000b 


Data = 
A Control 
B Control 


00000003 
= Burst Read 
= Burst Read 


00000003 
Word 3 
Word 3 


00000003 


C Control 


= Burst Read 


Word 3 





Bus cycles 5 through 8 correspond to a Burst Read from 
EPROM addresses IFCOOOIOh through IFCOOOICh. Again the data 
read corresponds to the data programmed into the Verilog 
EPROM module in Appendix C, Section I. 
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5. 


Address = 
Control = 
Data = 
A Control 
B Control 
C Control 


IfcOOOlO 
00000008 
00000004 
= Burst Read 
= Burst Read 
= Burst Read 


IfcOOOlO 
00000008 
00000004 
Word 0 
Word 0 
Word 0 


IfcOOOlO 

00000008 

00000004 


6 . 


Address = 


IfcOOOlO 


IfcOOOlO 


IfcOOOlO 




Control = 


00000009 


00000009 


00000009 




Data = 
A Control 
B Control 
C Control 


00000005 
= Burst Read 
= Burst Read 
= Burst Read 


00000005 
Word 1 
Word 1 
Word 1 


00000005 


7 . 


Address = 


IfcOOOlO 


IfcOOOlO 


IfcOOOlO 




Control = 


0000000a 


0000000a 


0000000a 




Data = 
A Control 
B Control 
C Control 


00000006 
= Burst Read 
= Burst Read 
= Burst Read 


00000006 
Word 2 
Word 2 
Word 2 


00000006 


8. 


Address = 


IfcOOOlO 


IfcOOOlO 


IfcOOOlO 




Control = 


0000000b 


0000000b 


0000000b 




Data = 
A Control 
B Control 
C Control 


00000007 
= Burst Read 
= Burst Read 
= Burst Read 


00000007 
Word 3 
Word 3 
Word 3 


00000007 


Bus 


cycles 9 


through 12 


correspond 


to four Write 



cycles to RAM addresses OOOOOOOOh/ 00000004h/ OOOOOOOSh/ and 
OOOOOOOCk. 



9. 


Address - 


00000000 


00000000 


00000000 




Control = 


00000034 


00000034 


00000034 




Data = 


11111111 


11111111 


11111111 




A Control 


= Write 








B Control 


= Write 








C Control 


= Write 






10 . 


Address = 


00000000 


00000000 


00000000 




Control = 


00000035 


00000035 


00000035 




Data = 


22222222 


22222222 


22222222 




A Control 


= Write 








B Control 


= Write 








C Control 


= Write 







Address = 


00000000 


00000000 


00000000 


Control = 


00000036 


00000036 


00000036 


Data = 


33333333 


33333333 


33333333 


A Control 


= Write 






B Control 


= Write 






C Control 


= Write 
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12. Address = 00000000 00000000 00000000 

Control = 00000037 00000037 00000037 

Data = 44444444 44444444 44444444 

A Control = Write 

B Control = Write 

C Control = Write 



Bus cycle 13 corresponds to a single word Read bus 



cycle from RAM address OOOOOOOOh. The data read is the same 

that was written during cycle 9 . 

13. Address = 00000000 00000000 00000000 

Control = 00000018 00000018 00000018 

Data = 11111111 11111111 11111111 

A Control = Read 
B Control = Read 
C Control = Read 



Bus cycles 14 through 17 correspond to a Burst Read 
from RAM addresses OOOOOOOOh through OOOOOOOCr. The data 
read from RAM is the same that was written during cycles 9 
through 12 . 

14. Address = 00000000 00000000 00000000 

Control = 00000008 00000008 00000008 

Data = 11111111 11111111 11111111 

A Control = Burst Read Word 0 
B Control = Burst Read Word 0 
C Control = Burst Read Word 0 



15. Address = 00000000 00000000 00000000 

Control = 00000009 00000009 00000009 

Data = 22222222 22222222 22222222 

A Control = Burst Read Word 1 
B Control = Burst Read Word 1 
C Control = Burst Read Word 1 



16. Address = 00000000 00000000 00000000 

Control = 0000000a 0000000a 0000000a 

Data = 33333333 33333333 33333333 

A Control = Burst Read Word 2 
B Control = Burst Read Word 2 
C Control = Burst Read Word 2 
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17. Address = 00000000 00000000 00000000 

Control = 0000000b 0000000b 0000000b 

Data = 44444444 44444444 44444444 

A Control = Burst Read Word 3 
B Control = Burst Read Word 3 
C Control = Burst Read Word 3 



B. INJECTED ERROR RESULTS 



Bus cycles 1 through 4 correspond to a Burst Read from 
EPROM addresses IFCOOOOOh through IFCOOOOCh. The data read 
corresponds to the data programmed into the Verilog® EPROM 



module in Appendix C, Section I. 



CPU A CPU B CPU c 



Address = 
Control = 
Data = 
A Control 
B Control 
C Control 


IfcOOOOO 
00000008 
00000000 
= Burst Read 
= Burst Read 
= Burst Read 


IfcOOOOO 
00000008 
00000000 
Word 0 
Word 0 
Word 0 


IfcOOOOO 

00000008 

00000000 


Address = 


IfcOOOOO 


IfcOOOOO 


IfcOOOOO 


Control = 


00000009 


00000009 


00000009 


Data = 


00000001 


00000001 


00000001 


A Control 


= Burst Read 


Word 1 




B Control 


= Burst Read 


Word 1 




C Control 


= Burst Read 


Word 1 




Address = 


IfcOOOOO 


IfcOOOOO 


IfcOOOOO 


Control = 


0000000a 


0000000a 


0000000a 


Data = 


00000002 


00000002 


00000002 


A Control 


= Burst Read 


Word 2 




B Control 


= Burst Read 


Word 2 




C Control 


= Burst Read 


Word 2 




Address = 


IfcOOOOO 


IfcOOOOO 


IfcOOOOO 


Control = 


0000000b 


0000000b 


0000000b 


Data = 


00000003 


00000003 


00000003 


A Control 


= Burst Read 


Word 3 




B Control 


= Burst Read 


Word 3 




C Control 


= Burst Read 


Word 3 





Cycle 5 is a Write bus cycle to RAM address OOOOOOOOh 
where there is an error in the address of processor A. 



83 



5. Address = 00000100 
Control = 00000034 
Data = 11111111 
A Control = Write 
B Control = Write 
C Control = Write 



00000000 

00000034 

11111111 



00000000 

00000034 

11111111 



Cycles 6 through 11 are the six cycles of the simulated 
interrupt service routine. The differences between the 
"internal" information of the three processors that caused 
the error can be observed. These differences do not 



themselves cause additional vote error interrupts because 



the interrupt routines are initiated by a write to "dummy" 



address 
is read 

6. 


IFSOxxxxh . 

back from 

Address = 
Control = 
Data = 

A Control 
B Control 
C Control 


However 

RAM, the 

IfSOOOOO 
00000034 
ffffffff 
= Write 
= Write 
= Write 


, when the " 

"corrected" 

IfSOOOOO 

00000034 

ffffffff 


internal" information 

information is read. 

IfSOOOOO 

00000034 

ffffffff 


7 . 


Address = 


00070000 


00070000 


00070000 




Control = 


00000034 


00000034 


00000034 


8 . 


Data = 
A Control 
B Control 
C Control 


00000100 
= Write 
= Write 
= Write 


00000000 


00000000 


Address = 


00070000 


00070000 


00070000 




Control = 


00000035 


00000035 


00000035 




Data = 
A Control 
B Control 
C Control 


11111111 
= Write 
= Write 
= Write 


11111111 


11111111 


9. 


Address = 


00070000 


00070000 


00070000 




Control = 


00000018 


00000018 


00000018 




Data = 
A Control 
B Control 


00000000 
= Read 
= Read 


00000000 


00000000 




C Control 


= Read 
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10 . 



11 . 



Address = 
Control = 
Data = 
A Control 
B Control 
C Control 

Address = 
Control = 



00070000 
00000019 
11111111 
= Read 
= Read 
= Read 

IfSOOOOO 

00000034 

ffffffff 



00070000 

00000019 

11111111 



IfSOOOOO 

00000034 

ffffffff 



00070000 

00000019 

11111111 



IfSOOOOO 

00000034 

ffffffff 



Data 

A Control = Write 
B Control = Write 
C Control = Write 



Cycle 12 is a Write bus cycle to RAM address 00000004h 



where there is an error in the address of processor B. 



Cycles 13 through 18 are the simulated interrupt service 



routine initiated by the three processors. 



12 . 


Address = 
Control = 
Data = 
A Control 
B Control 
C Control 


00000000 
00000035 
22222222 
= Write 
= Write 
= Write 


01000000 

00000035 

22222222 


00000000 

00000035 

22222222 


13. 


Address = 


IfSOOOOO 


IfSOOOOO 


IfSOOOOO 




Control = 


00000034 


00000034 


00000034 




Data = 


ffffffff 


ffffffff 


ffffffff 




A Control 


= Write 








B Control 


= Write 








C Control 


= Write 






14 . 


Address = 


00070000 


00070000 


00070000 




Control = 


00000034 


00000034 


00000034 




Data = 


00000004 


01000004 


00000005 




A Control 


= Write 








B Control 


= Write 








C Control 


= Write 






15. 


Address = 


00070000 


00070000 


00070000 




Control = 


00000035 


00000035 


00000035 




Data = 


22222222 


22222222 


22222222 




A Control 


= Write 








B Control 


= Write 








C Control 


= Write 






16. 


Address = 


00070000 


00070000 


00070000 




Control = 


OOOOOOIS 


OOOOOOIS 


OOOOOOIS 




Data = 


00000004 


00000004 


00000004 




A Control 


= Read 








B Control 


= Read 








C Control 


= Read 
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Address = 
Control = 
Data = 
A Control 
B Control 
C Control 


00070000 
00000019 
22222222 
= Read 
= Read 
= Read 


00070000 

00000019 

22222222 


00070000 

00000019 

22222222 


Address = 


IfSOOOOO 


IfSOOOOO 


IfSOOOOO . 


Control = 


00000034 


00000034 


00000034 


Data = 


ffffffff 


ffffffff 


ffffffff • 


A Control 


= Write 






B Control 


= Write 






C Control 


= Write 







Cycle 19 is a Write bus cycle to RAM address OOOOOOOSh 
where there is an error in the data of processor C. Cycles 
20 through 25 are the simulated interrupt service routine 



initiated by the three processors. 



19. 


Address = 
Control = 
Data = 
A Control 
B Control 
C Control 


00000000 
00000036 
33333333 
= Write 
= Write 
= Write 


00000000 

00000036 

33333333 


00000000 

00000036 

33333337 


20. 


Address = 


IfSOOOOO 


IfSOOOOO 


IfSOOOOO 




Control = 


00000034 


00000034 


00000034 




Data = 
A Control 
B Control 
C Control 


ffffffff 
= Write 
= Write 
= Write 


ffffffff 


ffffffff 


21. 


Address = 


00070000 


00070000 


00070000 




Control = 


00000034 


00000034 


00000034 




Data 

A Control 
B Control 
C Control 


00000008 
= Write 
= Write 
= Write 


00000008 


00000008 


22. 


Address = 


00070000 


00070000 


00070000 




Control = 


00000035 


00000035 


00000035 




Data = 
A Control 
B Control 
C Control 


33333333 
= Write 
= Write 
= Write 


33333333 


33333337 


23. 


Address = 


00070000 


00070000 


00070000 




Control = 


OOOOOOIS 


OOOOOOIS 


OOOOOOIS 




Data = 
A Control 
B Control 


ooooooos 

= Read 
= Read 


ooooooos 


ooooooos 




C Control 


= Read 







86 



Address = 
Control = 
Data = 
A Control 
B Control 
C Control 


00070000 
00000019 
33333333 
= Read 
= Read 
= Read 


00070000 

00000019 

33333333 


00070000 

00000019 

33333333 


Address = 


IfSOOOOO 


IfSOOOOO 


IfSOOOOO 


Control = 


00000034 


00000034 


00000034 


Data = 


ffffffff 


ffffffff 


ffffffff 


A Control 


= Write 






B Control 


= Write 






C Control 


= Write 







Cycle 26 is a Write bus cycle to RAM address OOOOOOOAh 



where there are multiple errors in the data of all three 
processors. Cycles 27 through 32 are the interrupt service 
routine . 



26. 


Address = 
Control = 
Data = 
A Control 
B Control 
C Control 


00000000 
00000037 
f4444444 
= Write 
= Write 
= Write 


00000000 

00000037 

44a44444 


00000000 

00000037 

44444447 


27 . 


Address = 


IfSOOOOO 


IfSOOOOO 


IfSOOOOO 




Control = 


00000034 


00000034 


00000034 




Data = 
A Control 
B Control 
C Control 


ffffffff 
= Write 
= Write 
= Write 


ffffffff 


ffffffff 


28. 


Address = 


00070000 


00070000 


00070000 




Control = 


00000034 


00000034 


00000034 




Data = 
A Control 
B Control 
C Control 


0000000c 
= Write 
= Write 
= Write 


0000000c 


0000000c 


29. 


Address = 


00070000 


00070000 


00070000 




Control = 


00000035 


00000035 


00000035 




Data = 
A Control 
B Control 
C Control 


£4444444 
= Write 
= Write 
= Write 


44a44444 


44444447 


30. 


Address = 


00070000 


00070000 


00070000 




Control = 


00000018 


00000018 


00000018 




Data = 
A Control 
B Control 
C Control 


0000000c 
= Read 
= Read 
= Read 


0000000c 


0000000c 








============= 


=============== 
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31 . 



32. 



Address = 
Control = 
Data = 
A Control 
B Control 
C Control 


00070000 
00000019 
44444444 
= Read 
= Read 
= Read 


00070000 

00000019 

44444444 


00070000 

00000019 

44444444 


Address = 


IfSOOOOO 


IfSOOOOO 


IfSOOOOO V 


Control = 


00000034 


00000034 


00000034 


Data = 


ffffffff 


ffffffff 


ffffffff 


A Control 
B Control 
C Control 


= Write 
= Write 
= Write 







Cycles 33 through 36 are a Burst Read from RAM 
addresses OOOOOOOOh, 00000004h, OOOOOOOSh/ and OOOOOOOCh- 
The data read from RAM is the data which was "corrected" by 
the majority voter when written during cycles 5, 12, 19, and 
26. This example shows the successful completion of the 
four Write cycles (5, 12, 19, and 26) which contained 
errors. 



Address = 
Control = 
Data = 
A Control 
B Control 
C Control 


00000000 
ooooooos 
11111111 
= Burst Read 
= Burst Read 
= Burst Read 


00000000 
00000008 
11111111 
Word 0 
Word 0 
Word 0 


00000000 

00000008 

11111111 


Address = 


00000000 


00000000 


00000000 


Control = 


00000009 


00000009 


00000009 


Data = 
A Control 
B Control 
C Control 


22222222 
= Burst Read 
= Burst Read 
= Burst Read 


22222222 
Word 1 
Word 1 
Word 1 


22222222 


Address = 


00000000 


00000000 


00000000 


Control = 


0000000a 


0000000a 


0000000a 


Data = 
A Control 
B Control 
C Control 


33333333 
= Burst Read 
= Burst Read 
= Burst Read 


33333333 
Word 2 
Word 2 
Word 2 


33333333 


Address - 


00000000 


00000000 


00000000 


Control = 


0000000b 


0000000b 


0000000b 


Data = 
A Control 
B Control 


44444444 
= Burst Read 
= Burst Read 


44444444 
Word 3 
Word 3 


44444444 


C Control 


= Burst Read 


Word 3 
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Cycle 37 is a Write cycle to RAM address 00004000h 



where processor B has incorrectly initiated a burst read 
from 00004000h. Cycles 38 through 43 are the interrupt 
routine . 



37, 


Address = 
Control = 
Data = 
A Control 
B Control 
C Control 


00004000 
00000034 
78787878 
= Write 
= Burst Read 
= Write 


00004000 

00000008 

xxxxxxxx 

Word 0 


00004000 

00000034 

78787878 


38. 


Address = 


IfSOOOOO 


lf800000 


lf800000 




Control = 


00000034 


00000034 


00000034 




Data = 
A Control 
B Control 
C Control 


ffffffff 
= Write 
= Write 
= Write 


ffffffff 


ffffffff 


39, 


Address = 


00070000 


00070000 


00070000 




Control = 


00000034 


00000034 


00000034 




Data = 
A Control 
B Control 
C Control 


00004000 
= Write 
= Write 
= Write 


00004000 


00004000 


40. 


Address = 


00070000 


00070000 


00070000 




Control = 


00000035 


00000035 


00000035 




Data = 
A Control 
B Control 
C Control 


78787878 
= Write 
= Write 
= Write 


78787878 


78787878 


41. 


Address = 


00070000 


00070000 


00070000 




Control = 


00000018 


00000018 


00000018 




Data = 
A Control 
B Control 
C Control 


00004000 
= Read 
= Read 
= Read 


00004000 


00004000 


42 , 


Address = 


00070000 


00070000 


00070000 




Control = 


00000019 


00000019 


00000019 




Data = 


78787878 


78787878 


78787878 



A Control = Read 
B Control = Read 
C Control = Read 



Address = 


lf800000 


lf800000 


lf800000 


Control = 


00000034 


00000034 


00000034 


Data = 


ffffffff 


ffffffff 


ffffffff 


A Control 


= Write 






B Control 


= Write 






C Control 


= Write 
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Cycle 44 is a single word Read from RAM address 



00004000k 
cycle 37 . 
44 . 



The data read is the correct data written during 



Address = 
Control = 
Data = 
A Control 
B Control 
C Control 



00004000 
00000018 
78787878 
= Read 
= Read 
= Read 



00004000 

00000018 

78787878 



00004000 

00000018 

78787878 
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VI. CONCLUSION 



With the rapidly declining radiation hardened device 
market and high prices of such devices when compared to COTS 
alternatives, a tool is desired that will allow the 
observance and analysis of COTS processors operating in a 
radiation environment. Additional reasons to move towards 
COTS devices are significant advantages in efficiency, 
performance, and software availability. 

One of the primary disadvantages of COTS devices is 
their susceptibility to single event upsets. Triple Modular 
Redundancy (TMR) is viewed as one of many possible 
alternatives to provide some protection from SEUs in COTS 
devices . 

The danger of incorporating redundancy into a system is 
that the overall system reliability could be reduced, due to 
the increased number of components. If the redundant 
systems are not themselves reliable, there is little hope of 
improving the reliability of the system. 

The TMR Testbed design is not intended as a design for 
space flight operations. Nor is it intended as a guaranteed 
method of improving the performance of the R3081 processors 
in the presence of radiation induced single event upsets. 

The design herein is intended for ground based operational 
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testing of the voting logic and any software algorithms run 
within the processors themselves. It is assumed that the 
board can be constructed in such a way that all of the 
hardware, other than the microprocessors, can be adequately 
shielded during laboratory radiation testing. In addition, 
it is realized that a fault which occurs in two of the 
processors at the same time, and which is manifested as the 
same bit being flipped on the address, control, or data bus, 
cannot be detected. In the event this error occurs, the two 
processors which are actually "faulty" will agree and become 
the majority when passed to the majority voters. 

In the Testbed design, TMR provides the opportunity to 
monitor the three processors and in the event of an error, 
determine which processor was in error and what the 
processor was doing at the time the error occurred. 

The Cadence/Verilog® design will allow simulation of 

the concept, verification of timing signals, and flexibility 
in reconfiguration of the design. Through simulation, the 
use of the bus /memory interface from three COTS 
microprocessors in a TMR design to monitor the system for 
errors has been realized. The actual board design could be 
constructed and used to test voting logic hardware and 
software algorithms in a laboratory environment in the 
presence of radiation induced SEUs or injected faults. 
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The use of the dedicated FIFO memories allows both real 



time and post-error analysis of the state of the three 
microprocessors. Thus, the tool will provide the capability 
to analyze the success or failure of attempts to improve the 
performance of COTS microprocessors in this environment, 
prior to their use in designs intended for actual space 
applications . 
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APPENDIX A. TMR TESTBED DESIGN SCHEMATICS 



This appendix contains the entire schematic for the TMR 
Testbed built using Cadence Concept™ schematic tools and 

the Verilog® Hardware Description Language. 

Enlarged views of each block in the following 
schematics and associated Verilog® code, when applicable, 
are contained Appendices B and C. 
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Figure 31. 



TMR Testbed Schematic 



(1 of 11) . 
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Figure 32. 



TMR Testbed Schematic 



(2 of 11) . 
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Figure 33 . 



TMR Testbed Schematic (3 



of 11) . 
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Figure 34. 



Testbed Schematic (4 of 11) . 
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Figure 35. TMR Testbed Schematic (5 of 11) 
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Figure 36. TMR Testbed Schematic (6 of 11) 



101 



gpuuflQOR-;aji,.B^ 

c-CQNT<r,a^ 




Figure 37. TMR Testbed Schematic (7 of 11) . 
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Figure 38. 



TMR Testbed Schematic 



(8 of 11) . 
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Figure 39. 



TMR Testbed Schematic 



(9 of 11) . 
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Figure 40. TMR Testbed Schematic (10 of 11) 
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Figure 41. 



TMR Testbed Schematic (11 of 11) 



106 



APPENDIX B. CADENCE SUPPLIED MODULES 



This appendix contains the TMR Testbed schematic 
modules, which were supplied in the Cadence Concept™ 
schematic libraries. 

A. A74FCT373 TRANSPARENT LATCH 

This part was used to build the address demultiplexer. 
The body diagram of the address demultiplexer and its 
schematic follow. 
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Figure 42. A74FCT373 Transparent Latch. 
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Figure 43. Address Demultiplexer. 
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Figure 44. Address Demultiplexer Schematic 
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Figure 45. IDT71256 
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Figure 46. IDT72225LA 
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APPENDIX C 



. USER DEFINED VERILOG® MODULES 



This appendix contains the custom modules built using 
the Verilog® Hardware Description Language and the part body 

diagrams built using the Cadence Concept™ schematic tools. 



A. 



IDT R3081 RISC MICROPROCESSOR BUS SIMULATOR 



R3081 







ftD<3i. . 0> 


CURR_TRftNS<2. . 0> 
ADDRESS< 31. . 0>o_ 
□ftTA<3i. . 0>o- 


TRANB< 2. 
ADDR<3i. 
□ftTft<31. 


AD DR 2 

. 0> 

. 0> ADDR3 
. 0> 

ALE 


REBET_No- 


REBETjk 


RD;k 


ACK_N 0_ 


PiCKJk 


WRjk 


RDCEN_N0_ 


RDCENjk 


BURBT;k 


INT5_N 0^ 


INT5;*< 


□ATAENjk 






BYBCLKJk 



ftD<3i. . 0> 

ADDR2 

ADDR3 

pile: 

RD_N 

WR-.N 

BURBT_N 

DftTAE:N-.N 

SYSCLK-.N 



Figure 47. R3081 Microprocessor Bus Simulator. 



// 

// 

//* 

//* Description: Verilog behavioral file for simulating the 

I / '^ multiplexed address/data bus of a IDT RV3 081. 

//* 

//* Reference: (1) IDT79R3081 RISController with FPA Data Sheet 

//* (2) R3081 Family Hardware User's Guide 

/ /'^ 

//* Author: John C. Payne, Jr. 

//* Date: 10/24/98 

'timescale 1 ns /I ps 

'define NONE 0 

'define READ_BYTE 1 
'define READ_W0RD 2 



* File: r3081.v 
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'define READ_BURST 3 
'define WRITE_BYTE 4 
'define WRITE_WORD 5 



'define HIGH 1 
'define LOW 0 
'define TRUE 1 
'define FALSE 0 



^^if'^^irifif-kir-kirir-k-kiriririeirir-kir-k-k-k’k-k'k-k-k-kir-k-k-k'k-k'k'kirir-k-kir'k-k-k'k’k'kir-k-kir-k-k-kir'kir-kieir-kirie-k-kirifieir 

//* Module: r3081 

//* 

//* Description: Verilog behavioral module for simulating the 

//^ multiplexed address/data bus and control lines of the IDT R3081. 

//* This module drives the R3081 block in the Cadence Concept 

//* schematic. 

//* NOTE: Module name must match the Cadence Concept block name, but 

//* must be in lower case. Signal names of inout, input, and output 

//■^ lines and size (or bus width) must match the signal names in the 

//* Cadence Concept block. 

//* 

//* Reference: (1) IDT79R3081 RISController with FPA Data Sheet 

//* (2) R3081 Family Hardware User's Guide 



module r3081 (SYSCLK_N, RD_N, WR_N, AD, ADDR3 , ADDR2 , ALE, 
DATAEN^N, BURST_N, RDCEN_N, ACK_N, RESET^N, 
INT5_N, CURR_TRANS, ADDRESS, DATA) ; 



//■^ RV3081 @ 20MHz rise/fall time parameters (min , typ , max) 
parameter 



t7_min = 


0, 








t7_typ = 


2.5, 


//* 


t7 


= Valid from SYSCLK_N rising 


t7_max = 


5, 








t8_min = 


0, 








t8_typ = 


2, 




t8 


= Asserted from SYSCLK_N rising 


t8_max = 


4, 








t9_min = 


0, 








t9_typ = 


2, 


//* 


t9 


= Negated from SYSCLK_N falling 


1 9_max = 


4, 








tll_min 


= 0, 








tll_typ 


= 7.5, 


//* 


til 


= Asserted from SYSCLK_N falling 


tll_max 


= 15, 








tl4_min 


= 0, 








tl4_typ 


= 0, 


//* 


tl4 


= Driven from SYSCLK_N rising 


tl4_max 


= 0, 








tl5_min 


= 0, 








tl5_typ 


= 3.5, 


//* 


tl5 


= Negated from SYSCLK_N falling 


tl5_max 


= 7, 








tl6_min 


= 0, 








tl6_typ 


= 3, 


//* 


tl6 


= Valid from SYSCLK_N 


tl6_max 


= 6, 








tl8_min 


= 0, 








tl8_typ 


= 5, 


//* 


tl8 


= Tri-State from SYSCLK_N falling 


tl8_max 


= 10, 








tl9_min 


= 0, 








tl9_typ 


= 6.5, 


//* 


tl9 


= SYSCLK_N falling to data valid 


tl9_max 


= 13; 
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//* Module input and output lines 
output SYSCLK_N, 

RD_N, 

WR_N; 

inout [31:0] AD; 
output ADDR3 X 
ADDR2, 

ALE, 

DATAEN_N, 

BURST^N; 
input RDCEN_N, 

ACK_N, 

RESET_N, 

INT5_N; 

These three inputs are not actual pins on an IDT R3081. They 
//* are used as interface pins to the bus simulator to command the 
//* bus to initiate a read, burst read, or a write, 
input [2:0] CURR^TRANS; 
input [31:0] ADDRESS; 
input [31:0] DATA; 

reg SYSCLK^N; 

wire RD_N, ADDR3 , ADDR2 , ALE, DATAEN_N, BURST_N; 

//^ Internal variables (line enables) 

reg RD_N_enable; 

reg WR_N_enable; 

reg AD_enable; 

reg ADDR3_enable ; 

reg ADDR2_enable; 

reg ALE_enable; 

reg DATAEN_N_enable; 

reg BURST_N_enable ; 

reg [31:0] busValue; 

reg startCycle; 

reg bootCycle; 

reg [31 ;0] saveAddress; 

reg [31:0] saveData; 

//* R3081 Multiplexed Address/Data Bus (32 bit) 
busDriver # { tl4_min, tl4_typ, tl4_max, 

tl8_min, tl8_typ, tl8_max, 
tl8_min, tl8_typ, tl8_max) 

ADBus(AD, busValue, AD_enable) ; 

//* R3081 Output Line RD_N Driver 
activeLowLineDriver 

# ( tl5_min, tl5_typ, tl5_max, t7_min, t7_typ, t7_max) 

RDLine (RD_N, RD_N_enable) ; 

//* R3081 Output Line WR_N Driver 
activeLowLineDriver 

# { tl5_min, tl5_typ, tl5_max, t7_min, t7_cyp, t7_max) 

WRLine{WR_N, WR_N_enable) ; 
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//* R3081 Output Line ADDR3 Driver 
activeHighLineDriver 

# ( tl6_min, tl6_typ, tl6_max, tl6_min, tl6_typ, tl6_max) 

ADDR3Line(ADDR3, ADDR3_enable) ; 

//* R3081 Output Line ADDR2 Driver 
activeHighLineDriver 

# (tl6_min, tl6_typ, tl6_max, tl6_min, tl6_typ, tl6_max) , 

ADDR2Line (ADDR2 , ADDR2_enable) ; 

//* R3081 Output Line ALE Driver 
activeHighLineDriver 

# ( t8_min, t8_typ, t8_max, t9_min, t9_typ, t9_max) 

ALELine (ALE, ALE_enable) ; 

//* R3081 Output Line DATAEN_N Driver 
activeLowLineDriver 

# (tl5_min, tl5_typ, tl5_max, tll_min, tll_typ, tll_max) 

DATAENLine(DATAEN_N, DATAEN_N_enable) ; 

//* R3081 Output Line BURST_N Driver 
activeLowLineDriver 

# (tl5_min, tl5_typ, tl5_max, t7_min, t7_typ, t7_max) 

BURSTLine (BURST_N, BURST_N_enable) ; 

//* Initialize internal variables 

initial 

begin 

SYSCLK_N = 0; 

RD_N_enable = 'LOW; 

WR_N_enable = 'LOW; 

AD_enable = 'LOW; 

ADDR3_enable = 'LOW; 

ADDR2_enable = 'LOW; 

ALE_enable = 'LOW; 

DATAEN_N_e n a b 1 e = 'LOW; 

BURST_N_enable = 'LOW; 
busValue = 'bz; 
startCycle = 'FALSE; 
saveAddress = 'bz; 
saveData = ' bz ; 

end 

//* Control System Reference Clock 
always 

#2 5 SYSCLK_N = SYSCLK_N; 

Watch for change in CURR_TRANS input. If there is not a cycle 
//* already started (startCycle = FALSE), then start a new cycle, 
always 0 ( CURR^TRANS ) 
if (StartCycle) 

StartCycle = 'FALSE; 
else if (CURR^TRANS == 'NONE) 

StartCycle = 'FALSE; 
else 

StartCycle = 'TRUE; 
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//* At each positive edge of the system reference clock, if the 
//* RESET_N input line is low, then set up system for initial burst 
//* read from ROM at address IFCOOOOO 
always @(posedge SYSCLK_N) 
begin 

if (!RESET_N) 

begin 

busValue = 32 ^ hlFCOOOOO ; 

AD_enable = 'HIGH; 
wait {RESET_N == 1) ; 
bootCycle = 'TRUE; 

end 

end 

//* Watch for negative edge of the interrupt line INT5_N. If a 
//* cycle is currently in progress, then it is a cycle that hasn^t 
//* finished because of an incorrect control input. This means 
//* that if, for example, this R3081 initiated a READ while the 
//* other two R3081's initiated a WRITE, it will be stuck waiting 
//* for signals from the memory controller which are associated 
//* with a READ. These signals will not come as expected because 
//* the system completed a WRITE cycle based on the voted majority 
//* from the other two R3081's. After interrupting waiting 
//* processor (if necessary), perform simulated, abbreviated 
//* interrupt handler routine, beginning and ending the routine with 
//* a WRITE to "dummy address" 1F800000 
always © (negedge INT5_N) 
begin 

if ( ! startCycle) //* Then cycle is in progress 

case (CURR_TRAMS [2 : 0] ) //* Interrupt waiting cycle 

3'bOOl: 

begin //* Interrupt a waiting READ_BYTE cycle 
disable readByte; 

@ (negedge SYSCLK_N) 
begin 

RD_N_enable = 'LOW; 

DATAEN_N_enable = 'LOW; 

ADDR3_enable = 'LOW; 

ADDR2_enable = 'HIGH; 

@(posedge SYSCLK_N) ; 
end 

end 

3'bOlO: 

begin //* Interrupt a waiting READ_WORD cycle 
disable readWord; 

@ (negedge SYSCLK_N) 
begin 

RD_N_enable = 'LOW; 

DATAEN_N_enable = 'LOW; 

ADDR3_enable = 'LOW; 

ADDR2_enable = 'HIGH; 

(posedge SYSCLK_N) ; 
end 

end 
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3'bOlli 

begin //* Interrupt a waiting READ_BURST cycle 
disable readBurst; 

@(negedge SYSCLK^N) 
begin 

RD_N_enable = 'LOW; 

ADDR3_enable = 'LOW; 

ADDR2_enable = 'LOW; ; 

DATAEN_N_enable = 'LOW; 

BURST_N_enabl e = ' LOW ; 

@(posedge SYSCLK_N) ; 
end 

end 

3'blOO: 

begin //* Interrupt a waiting WRITE_BYTE cycle 
disable writeByte; 

@(negedge SYSCLK_N) 

WR_N_enable = 'LOW; 

@(posedge SYSCLK.N) 
begin 

AD_enable = 'LOW; 

ADDR3_enable = 'LOW; 

ADDR2_enable = 'LOW; 

end 

end 

3'blOl: 

begin //* Interrupt a waiting WRITE_WORD cycle 
disable writeWord; 

@(negedge SYSCLK_N) 

WR_N_enable = 'LOW; 

©(posedge SYSCLK_N) 
begin 

AD_enable = 'LOW; 

ADDR3_enable = 'LOW; 

ADDR2_enable = 'LOW; 
end 

end 

endcase 

//* The saved address and data information from the last bus 
//* cycle which caused the interrupt is used here simply to 
//* show that differences between the three processors will 
//* not cause a vote error interrupt to be generated due to 
//* the WRITE to "dummy address" 1F800000. The use of the 
//* saved address and data information is not intended to 
//* show what would actually be written during an interrupt 
//* routine. 

writeWord(32'hlF800000, 32 ' hFFFFFFFF) ; 
if (saveAddress[31:0] >= 32 ' hOOOOOOOO ) 

writeWord(32 'hOOOTOOOO , saveAddress) ; 
else 

writeWord(32'h00070000, 32 ' hA5A5A5A5 ) ; 
if (saveData[31: 0] >= 32 ' hOOOOOOOO ) 

writeWord(32 'h00070004 , saveData) ; 
else 

writeWord(32'h00070004. 32 ' h78787878 ) ; 
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readWord(32 'h00070000) ; 
readWord(32 'hO 007 00 04) ; 
writeWord(32 'hlFSOOOOO, 32 ' hFFFFFFFF) ; 



end 

//* Initiate appropriate bus cycles based on CURR__TRANS input, and 
Z/’" if startCyle is TRUE, or if a boot cycle is necessary. 

//* See the simulated, abbreviated interrupt handler routine above 
//* for how the saved address and data information is used, 
always 
begin 

if (startCycle ScSc (CURR^TRANS == 'READ_BYTE) ScSc IbootCycle) 
begin 

saveAddress = ADDRESS; 
saveData = DATA; 
readByte (ADDRESS) ; 

end 

else if (StartCycle ScSc (CURR_TRANS == 'READ_WORD) ScSc IbootCycle) 
begin 

saveAddress = ADDRESS; 
saveData = DATA; 
readWord (ADDRESS) ; 

end 

else if ((StartCycle ScSc (CURR^TRANS == 'READ_BURST) ) 

I I bootCycle) 

begin 

saveAddress = ADDRESS; 
saveData = DATA; 
readBurst (ADDRESS) ; 

end 

else if (StartCycle ScSc (CURR_TRANS == 'WRITE_BYTE) ScSc 
! bootCycle) 

begin 

saveAddress = ADDRESS; 

saveData = DATA; 

writ eBy t e ( ADDRESS , DATA ) ; 

end 

else if (StartCycle ScSc (CURR_TRANS == 'WRITE_WORD) ScSc 
IbootCycle) 

begin 

saveAddress = ADDRESS; 
saveData = DATA; 
writeWord (ADDRESS, DATA) ; 

end 

else 

@(posedge SYSCLK^N) ; 

end 
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//* task: readByte 

//* 

//* Description: Simulates the bus cycle for reading a byte from the 

//^ given address by driving the A/D bus and associated control 
//* lines. It waits on the RDCEN_N input from the memory 

//^ controller to indicate the memory has placed valid data on the 

//■* bus to read. 

//* 

//* Reference: (1) IDT79R3081 RISController with FPA Data Sheet 

//* (2) R3081 Family Hardware User's Guide 

task readByte; 

input [31:0] address; 



begin : readByte 

@ (posedge SYSCLK_N) 
begin 

startCycle = 'FALSE; 
busValue [31 : 4] = address [31:4]; 



//^ Set BE [3:0] 
busValue [3] = ! 
busValue [2] = ! 
busValue [1] = i 
busValue [0] = ! 



lines 

(address[l] Sc& address [0]); 
(address[l] && !address[0]); 
(! address [1] 5c& address[0]); 
(! address [1] && ! address [0]); 



AD_enable = 'HIGH; 

RD_N_enable = 'HIGH; 

ADDR3_enable = address [3]; //* Set word address 
ADDR2_enable = address [2]; 

ALE_enable = 'HIGH; 

end 



@(negedge SYSCLK_N) 
begin 

AD_enable = 'LOW; 
DATAEN_N_enable = 'HIGH; 
ALE_enable = 'LOW; 

end 

@ (posedge RDCEN_N) ; 

@(negedge SYSCLK_N) 
begin 

RD_N_enable = 'LOW; 
DATAEN_N_enab 1 e = ' LOW ; 
ADDR3_enable = 'LOW; 
ADDR2_enable = 'LOW; 

end 

end 

endtask //* end task readByte 
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//* task: readWord 

//* 

//* Description: Simulates the bus cycle for reading a word from the 

//* given address by driving the A/D bus and associated control 
//* lines. It waits on the RDCEN_N input from the memory 

//* controller to indicate the memory has placed valid data on the 

/ / * bus to read . 

//* 

//* Reference: (1) IDT79R3081 RISController with FPA Data Sheet 

//* (2)R3081 Family Hardware User's Guide 

task readWord; 

input [31:0] address; 

begin : readWord 

@(posedge SYSCLK_N) 
begin 

startCycle = 'FALSE; 
busValue [31 : 4] = address [ 3 1 : 4 ] ; 

//'^ Set BE[3:0] lines 
busValue [3] = 'LOW; 
busValue [2] = 'LOW; 
busValue [1] = 'LOW; 
busValue [0] = 'LOW; 

AD_enable = 'HIGH; 

RD_N_enable = 'HIGH; 

ADDR3_enable = address [3]; //* Set word address 

ADDR2_enable = address [2 ]; 

ALE_enable = 'HIGH; 

end 

@(negedge SYSCLK_N) 
begin 

AD_enable = 'LOW; 

DATAEN_N_enable = 'HIGH; 

ALE_enable = 'LOW; 

end 

@ (posedge RDCEN_N) ; 

@(negedge SYSCLK_N) 
begin 

RD_N_enable = 'LOW; 

DATAEN_N_enable = 'LOW; 

ADDR3_enable = 'LOW; 

ADDR2_enable = 'LOW; 

end 

end 

endtask //* end task readWord 
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//* task: readBurst 

//* 

//* Description: Simulates the bus cycle for burst reading four 

//* contiguous words of memory starting at the given address 

//* by driving the A/D bus and associated control lines. 

//* It waits on the RDCEN_N four times input from the memory 
//* controller to indicate the memory has placed valid data on 
//* the bus to read. 

//^ 

//* Reference: (1) IDT79R3081 RISController with FPA Data Sheet 

//* (2)R3081 Family Hardware User's Guide 

task readBurst; 

input [31:0] address; 



begin : readBurst 

@(posedge SYSCLK_N) 
begin 

startCycle = 'FALSE; 
if (ibootCycle) 

//* If it is a boot cycl 
//* be in busValue [31 : 0 ] 



e, IFCOOOOO will already 
for initial EPROM read 



begin 

busValue [31:4] 

//* Set BE [3 
busValue [3] 
busValue [2] 
busValue [1] 
busValue [ 0 ] 

end 



= address [31:4] ; 



:0] lines 
= 'LOW; 

= 'LOW; 

= 'LOW; 

= 'LOW; 



bootCycle = 'FALSE; 

AD^enable = 'HIGH; 

RD_N_enable = 'HIGH; 

ADDR3_enable = 'LOW; //* Set word address of 1st word 
ADDR2_enable = 'LOW; 

ALE_enable = 'HIGH; 

BURST_N_enable = 'HIGH; 

end 

@(negedge SYSCLK_N) 
begin 

AD_enable = 'LOW; 

DATAEN_N_enable = 'HIGH; 

ALE_enable = 'LOW; 

end 

@(posedge RDCEN_N) ; //^ Wait for 1st word 

@{negedge SYSCLK_N) 
begin 

ADDR2_enable = 'HIGH; //* Set word address of 2nd word 

end 

@(posedge RDCEN_N) ; //* Wait for 2nd word 
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@{negedge SYSCLK_N) 
begin 

ADDR3_enable = 'HIGH; //* Set word address of 3rd word 
ADDR2_enable = 'LOW; 

end 

@{posedge RDCEN_N) ; //* Wait for 3rd word 

@(negedge SYSCLK_N) 
begin 

ADDR2_enable = 'HIGH; //* Set word address of 4th word 
end 

@(posedge RDCEN_N) ; //* Wait for 4th word 

@{negedge SYSCLK_N) 
begin 

RD_N_enable = 'LOW; 

ADDR3_enable = 'LOW; 

ADDR2_enable = 'LOW; 

DATAEN_N_enable = 'LOW; 

BURST_N_enable = 'LOW; 

end 

end 

endtask //* end task readBurst 



J 1'k'ir'it'k'k'k'^'k'^'^'ir'^'k’k'ie’k'k‘k'^'ir'ie'k'k'k'k'k'k'^'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k-k'k'k'k'k'ic'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

/ / '^ task: writeByte 

//* 

//* Description: Simulates the bus cycle for writing a byte of the 

//* given data at the given address by driving the A/D bus and 

//* associated control lines. It waits on the ACK_N input from 

//* the memory controller to indicate the data has been written. 

//* 

//* Reference: (1) IDT79R3081 RISController with FPA Data Sheet 

//* (2) R3081 Family Hardware User's Guide 

^ ^•ieie'k'k'kie'ie'k'k'k'ir'k'k'k'k'k'ie'kir-k’k'k'k'k'k'k'k'k'k'k’k’k'k’k-k'k'k'ie'k'k'k'k-k’k’k-k'ie'kir'k'k-k'k’k'k-k-k-k'k'k’k’k'kir'k'k'k 

task writeByte; 

input [31:0] address, data; 



begin : writeByte 

@{posedge SYSCLK_N) 
begin 

startCycle = 'FALSE; 



busValue[31 :4] 


= address [31 


:4] 




//* Set BE[3:0] 


lines 






busValue[3] = i 


{address [1] 


ScSc 


address [0] ) 


busValue[2] = ! 


(address [1] 


ScSc 


i address [ 0 ] 


busValue[l] = ! 


( ! address [1] 


5c 5c 


address [0] 


busValue[0] = ! 


( ! address [1] 


5c 5c 


! address [ 0 



AD_enable = 'HIGH; 

WR_N_enable = 'HIGH; 

ADDR3_enable = address[3]; //* Set word address 
ADDR2_enable = address [2]; 

ALE_enable = 'HIGH; 

end 



121 



0(negedge SYSCLK_N) 
begin 

ALE_enable = 'LOW; 

# ( tl9_min : tl9_typ : tl9_max) 
busValue = data; 

end 

@(posedge ACK_N) ; 

0(negedge SYSCLK_N) 
begin 

WR_N_enable = 'LOW; 

end 

0(posedge SYSCLK_N) 
begin 

AD_enable = 'LOW; 
ADDR3_enable = 'LOW; 
ADDR2_enable = 'LOW; 

end 

end 

endtask //* end task writeByte 



//* task: writeWord 

//* 

//* Description: Simulates the bus cycle for writing a word of 

//* given data at the given address by driving the A/D bus and 

//* associated control lines. It waits on the ACK_N input from 

//* the memory controller to indicate the data has been written. 

//* 

//* Reference: (1) IDT79R3081 RISController with FPA Data Sheet 

//* (2) R3081 Family Hardware User's Guide 

I ^★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★** 

task writeWord; 

input [31:0] address, data; 

begin: writeWord 

0(posedge SYSCLK_N) 
begin 

startCycle = 'FALSE; 

busValue [31 : 4] = address [ 3 1 : 4 ] ; 



//* Set BE[3:0] lines 
busValue [3] = 'LOW; 
busValue [2] = 'LOW; 
busValue [1] = 'LOW; 
busValue [0] = 'LOW; 

AD_enable - 'HIGH; 

WR_N_enable = 'HIGH; 

ADDR3_enable = address [3]; //* Set word address 

ADDR2_enable = address [2]; 

ALE_enable = 'HIGH; 

end 
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& (negedge SYSCLK_N) 
begin 

ALE_enable = 'LOW; 

# ( tl9_min : tl9_typ: tl9_max) 
busValue = data; 

end 

@(posedge ACK_N | | ] INT5_N) ; 

Q (negedge SYSCLK_N) 
begin 

WR_N_enabl e = ' LOW ; 

end 

@(posedge SYSCLK^N) 
begin 

AD_enable = 'LOW; 
ADDR3_enable = 'LOW; 
ADDR2_enable = 'LOW; 

end 

end 

endtask //* end task writeWord 
endmodule //* end module r3081 



//* Module: busDriver 

//* 

//* Description: Assigns valueToGo to address /data bus when driveEnable 

//* is HIGH, otherwise drives bus to high impedance. 

module busDriver (busLine, valueToGo, driveEnable); 

parameter //* Parameters may be overridden for each 

//* instantiation of this module 



R_min 


= 


0, 


//* 


Minimum 


Rise 


Time 




R_cyp 


= 


2, 


//* 


Typical 


Rise 


Time 




R_max 


= 


4, 


//* 


Maximum 


Rise 


Time 




F_min 


= 


0, 


//* 


Minimum 


Fall 


Time 




F_typ 


= 


2, 


//* 


Typical 


Fall 


Time 




F_max 


= 


4, 


//* 


Maximum 


Fall 


Time 




Z_min 


= 


0, 


//* 


Minimum 


Time 


to high 


impedance 


Z-typ 


= 


2, 


//* 


Typical 


Time 


to high 


impedance 


Z_max 


= 


4; 


//* 


Maximum 


Time 


to high 


impedance 



inout [31:0] busLine; 
input [31:0] valueToGo; 
input driveEnable ; 



assign # (R_min : R_typ : R_max, F_min : F_typ : F_max, Z_min : Z_typ : Z_max) 
busLine = (driveEnable) ?valueToGo : 'bz ; 

endmodule //* end module busDriver 
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//* Module: activeLowLineDriver 

//* 

//* Description: Drives contLine LOW when driveEnable is HIGH, 

//* otherwise contLine remains HIGH. 

I ^★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★^★★★^r****************>-**'*r*****'»r********* 

module activeLowLineDriver (contLine, driveEnable) ; 

parameter //* Parameters may be overridden for each 

//* instantiation of this module 



R_ 


_min = 


0, 


//* 


Minimum 


Rise 


Time 


R_ 


-typ = 


2, 


//* 


Typical 


Rise 


Time 


R_ 


.max = 


4, 


//* 


Maximum 


Rise 


Time 


F_ 


_min = 


0, 


//* 


Minimum 


Fall 


Time 


F_ 


-typ = 


2, 


//* 


Typical 


Fall 


Time 


F_ 


_max = 


4; 


//* 


Maximum 


Fall 


Time 



inout contLine; 
input driveEnable ; 

assign # (R_min : R_typ : R_max, F_min : F_typ : F_max) 
contLine = (driveEnable) ?0 : 1 / 

endmodule //* end module activeLowLineDriver 



j |•k•^k•k•k'k•k'k^k•k•k^k•k^k^k^k^k•k■k•k•k•k'k•k^k^k^k'k'k•k•k•k^k^k^k•k•k^k^k•k•k^k■k•k^k•k•k^k•it•k•k'k^i(•k•k'k^k^k^k•k•k^k•k•k'k•k•k•k•k•k^^k 

//* Module: activeLowLineDriver 

//* 

//* Description: Drives contLine HIGH when driveEnable is HIGH, 

//* otherwise contLine remains LOW. 

module activeHighLineDriver (contLine, driveEnable) ; 

parameter //* Parameters may be overridden for each 

//* instantiation of this module 



R_min 


= 


0, 


//* 


Minimum 


Rise 


Time 


R_cyp 


= 


2, 


//* 


Typical 


Rise 


Time 


R_max 


= 


4, 


//* 


Maximum 


Rise 


Time 


F_min 


= 


0, 


//^ 


Minimum 


Fall 


Time 


F_typ 


= 


2, 


//* 


Typical 


Fall 


Time 


F_max 


= 


4; 


//* 


Maximum 


Fall 


Time 



inout contLine; 
input driveEnable; 

assign # (R_min : R_typ : R_max, F_min : F_typ : F_max) 
contLine = (driveEnable) ?1:0; 



endmodule //* end module activeHighLineDriver 
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B 



32 -BIT VOTER/ERROR DETECTOR MTD TRANSCEIVER 



U0TE32BIT_XCUR 



P<3i. . 0> 
B< 31 . . 0> 
C<3i. . 0> 
rORCE-P 
rORCE-B 
rORCE_C 



P<3i. . 0> 


U0TED_0UT<31. . 0> 


B<3i . . 0> 




C<3i. . 0> 


UOTE..ERROR 


rORCE^P 




rORCE.B 


RD)k 


rORCE_C 


WR>K 






-e 



UOTED^OUTOl. 

UOTE_ERROR 

RD_N 

WR_N 



. 0 > 



Figure 48. 32-Bit Voter/Error Detector and Transceiver. 



// 

// 

// 

// 

// 

// 

// 

// 

// 



* File: vote32bic_xcvr . v 

* Description: Verilog file for a 32 bit majority voter/error 

* detector and transceiver. 

* 

* Author: John C. Payne, Jr. 

* Date: 10/31/98 



'timescale 1 ns /I ps 

//* Module; bidirsw 

//* 

//* Description; Verilog behavioral module for a bidirectional switch 
//* with tristate. If CONT_LINE is high, then the INOUT_LINE 

//* information drives the LINE_OUT line (LINE^OUT = INOUT_LINE) ; 

//* otherwise, the LINE_0UT line is in a high impedance state. If 
//* C0NT_LINE is low, then the LINE_IN information drives the 

/r INOUT_LINE (INOUT_LINE = LINE_IN) ; otherwise, the INOUT_LINE line 

//* is in a high impedance state. 

module bidirsw (LINE-IN, ’LINE^OUT, INOUT^LINE, CONT_LINE) ; 

input LINE-IN; 
output LINE_OUT; 
inout INOUT_LINE; 
input C0NT_LINE; 

assign INOUT_LINE = ( ! C0NT_LINE) ?LINE_IN : ^ bz ; 
assign LINE_OUT = (CONT_LINE) ?INOUT_LINE : 'bz ; 

endmodule //* end module bidirsw 
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//^ Module: votecell_xcvr 

//* 

//* Description: Verilog structural module for a one bit voter/error 

/ detector and transceiver. Votes 3 input bits to produce 1 output 

//* bit. FORCE_A, FORCE_B, Sc FORCE^C inputs can be used to disable 

//* voting and force data on K, B, or C through to the output. 

//* Uses 4 bidirsw modules. 

I j'k-k-k’k-k'i^-k'k'k'k'k-k'k-k'k'k'k-k'k-k'k^'k'k'k'k'k'if'k-k'k’k'k'k’k'k'k’k-k'k'k'k'k'k'k’k’k'k'k'k'k'k'k'k'k'k'k-if'k-k'k-k-k^-k'k'tftf-k-k 

module votecell^xcvr (A, B. C. FORCE_A, FORCE_B, FORCE^C. RD_N, WR_N, 

MAJ_OUT, MAJ_ERROR) ; 

inout A, B, C; 

input FORCE^A, FORCE_B, FORCE_C, RD_N, WR_N; 
inout MAJ_OUT; 
output MAJ_ERROR; 
wire MAJORITY; 

tri IN_A, IN_B, IN_C, RD_IN; 



//* If RD_N is low, then RD_IN drives all three input /output lines 
//* A, B, Sc C; otherwise, A, B, Sc C drive IN_A, IN_B, Sc IN_C which 
//^ are then voted, 
bidirsw 

sw_l(RD_IN, IN_A, A, RD_N) , 
sw_2(RD_IN, IN_B, B, RD_N) , 
s w_3 ( RD_IN , IN_C , C , RD_N ) ; 

//* If WR_N is low, then MAJORITY drives the output line MAJ_OUT; 

//* otherwise, MAJ_OUT drives the RD_IN line. 

bidirsw 

sw_4 (MAJORITY, RD_IN, MAJ_OUT, WR_N) ; 



not 

not_l 

not_2 

not_3 

not_4 

not_5 

not_6 



(NOT_IN_A, IN_A) , 
(NOT_IN_B, IN_B) , 
(NOT_IN_C, IN_C) , 
(NOT_FORCE_A, FORCE_A) , 
(NOT_FORCE_B, FORCE_B) , 
(NOT_FORCE_C, FORCE_C) ; 



and 

and_l ( and_l_ou t , IN_A , 
and_2 (and_2_out, IN_B, 
and_3 ( and_3_out , IN_C , 
and_4 (and_4_out, IN_A, 
NOT_FORCE_C) , 
and_5 ( and_5_out , IN_A , 
NOT_FORCE_C) , 
and_6 (and_6_out, IN_B, 
NOT_FORCE_C ) ; 



FORCE_A) , 

FORCE^B) , 

FORCE_C) , 

IN_B, NOT_FORCE_A, NOT_FORCE_B, 
IN_C, NOT_FORCE_A, NOT_FORCE_B, 
IN_C, NOT_FORCE_A, NOT_FORCE_B, 



or #15 

or_l (MAJORITY, and_l_out, and_2_out, and_3_out, and_4_out, 
and_5_out, and_6_out) ; 
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and 



and_7 (and_7_out, NOT_IN_A, NOT_IN_B, IN_C, NOT_FORCE_A, 
NOT_FORCE_B, NOT_FORCE_C ) , 

and_8 (and_8_out, NOT_IN_A, IN_B, NOT_IN_C, NOT_FORCE_A, 
NOT_FORCE_B, NOT_FORCE_C ) , 

and_9 (and_9_out, NOT_IN_A, IN_B, IN_C, NOT_FORCE_A, NOT_FORCE_B, 
NOT_FORCE_C) , 

and_10 (and_10_out, IN_A, NOT_IN_B, NOT_IN_C, NOT_FORCE_A, 
NOT_FORCE_B, NOT_FORCE_C) , 

and_ll (and_ll_out, IN_A, NOT_IN_B, IN_C, NOT_FORCE_A, 
NOT_FORCE_B, NOT_FORCE_C) , 

and_12 (and_12_out, IN_A, IN_B, NOT_IN_C, NOT_FORCE_A, 
NOT_FORCE_B, NOT_FORCE_C) ; 

or #15 

or_2 (MAJ_ERROR, and_7_out, and_8_out, and_9_out, and_10_out, 
and_ll_out, and_12_out) ; 

endmodule //* end module votecell_xcvr 



yy'************************************************************-**'******** 

//* Module: vote8bit_xcvr 

//* 

//* Description: Verilog structural module for an 8 bit voter/error 

//* detector and transceiver. Votes 24 input bits to produce 8 

//^ output bits. FORCE_A, FORCE_B, Sc FORCE_C inputs can be used to 

//* disable voting and force data on A[7:0], B[7:0], or C[7:0] 

//* through to the output. Uses eight votecell_xcvr modules. 

module vote8bit_xcvr (A, B, C, FORCE_A, FORCE_B, FORCE_C, RD_N, WR_N, 

VOTED_OUT, VOTE_ERROR) ; 



inout [7:0] A, B, C; 

input FORCE_A, FORCE_B, FORCE_C; 

input RD_N, WR_N; 

inout [7:0] VOTED_OUT; 

output VOTE_ERROR; 

wire ERROR_0, ERROR_l, ERROR_2 , ERROR_3 , ERROR_4, ERROR_5 , ERROR_6 , 
ERROR_7 ; 

votecell_xcvr 



cello 


(A[0], B[0], Cl 
VOTED_OUT [ 0 ] , 


[0], FORCE_A, 
ERROR_0) , 


FORCE_B, 


FORCE_C , 


RD_N, 


WR_N, 


celll 


(A[l] , B[l] , Cl 
VOTED OUT[l], 


[1], FORCE_A, 
ERROR_l) , 


FORCE_B, 


FORCE_C , 


RD_N, 


WR_N, 


cell2 


(A[2] , B[2] , Cl 
VOTED OUT [2], 


[2], FORCE_A, 
ERROR_2 ) , 


FORCE_B, 


FORCE_C , 


RD_N, 


WR_N, 


cells 


(A[3] , B[3] , Cl 
VOTED OUT [ 3 ] , 


[3], FORCE_A, 
ERROR_3 ) , 


FORCE_B, 


FORCE_C , 


RD_N, 


WR_N, 


cell4 


(A[4] , B[4] , Cl 
VOTED OUT [4], 


[4], FORCE_A, 
ERROR_4 ) , 


FORCE_B, 


FORCE_C , 


rd_n. 


WR_N, 


cells 


(A[5] , B[5] , Cl 
VOTED_OUT [ 5 ] , 


[5], FORCE_A, 
ERROR_5 ) , 


FORCE_B, FORCE_C, 


RD_N, 


WR_N, 


cells 


(A[6] , B[6] , Cl 
VOTED OUT [ 6 ] , 


[6], FORCE_A, 
ERROR_6 ) , 


FORCE_B , FORCE_C , 


RD_N, 


WR_N, 


cell7 


(A[7] , B[7] , Cl 
VOTED_OUT [ 7 ] , 


[7], FORCE_A, 
ERROR_7 ) ; 


FORCE_B, FORCE_C, 


RD_N. 


WR_N, 
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or #10 

or_l (VOTE_ERROR, ERROR_0, ERROR_l , ERROR_2 , ERROR_3 , ERROR_4, 
ERROR_5 , ERROR_6 , ERROR_7 ) ; 

endmodule //* end module vote8bit_xcvr 



//* Module: vote32bit_xcvr 

//* 

//* Description: Verilog structural module for a 32 bit voter/error 

//* detector and transceiver. Votes 96 input bits to produce 32 

//* output bits. FORCE_A, FORCE_B, & FORCE_C inputs can be used 

//* to disable voting and force data on A[31:0], B[31:0], or C[31:0] 

//* through to the output. Uses four vote8bit_xcvr modules. 

//* This module drives the VOTE32BIT_XCVR block in the Cadence 
/ / * Concept schematic . 

Z/’" NOTE: Module name must match the Cadence Concept block name, but 

/ /* must be in lower case. Signal names of inout, input, and output 

//* lines and size {or bus width) must match the signal names in the 

//* Cadence Concept block. 

j j'k'if-k'k'k'if'k'k'k'k'^'k'k'k'k'k'k'it'k'k'k'k'k'k'k'k'k'k'k'k'k'k’k'k'k'k'k'k'k^'k'k'k'k'k'k'k'k'k’k'k’k'k'ic'k'k'k'if'k-k'if'k'k’k'k'k'k’k'k'k 

module vote32bit_xcvr (A, B, C, FORCE_A, FORCE_B, FORCE_C, 

RD_N, WR_N, VOTED_OUT, VOTE_ERROR) ; 



inout [31:0] A, B, C; 

input FORCE_A, FORCE_B, FORCE_C; 

input RD_N, WR_N; 

inout [31:0] VOTED_OUT; 

output VOTE_ERROR; 



wire ERROR_0, ERROR_l, ERROR_2 , ERROR_3 ; 



voteSbit xcvr 



FORCE_C, 



voterO (A[31:24], B[31:24], C[31:24], 

RD_N , WR_N , VOTED_OUT [31:24], 
voterl (A[23:16], B[23:16], C[23:16], 

RD_N , WR_N , VOTED_OUT [23:16], 
voter2 {A[15:8], B[15:8], C[15:8], FORCE_A, FORCE_B, FORCE_C, 
RD_N, WR_N, VOTED_OUT[15 : 8] , ERROR_2 ) , 
voter3 [A[7:0], B[7:0], C[7:0], FORCE_A, FORCE_B, FORCE_C, 
RD_N, WR_N, VOTED_OUT [7 : 0 ] , ERROR_3 ) ; 



FORCE_A, FORCE_B, 

ERROR_0 ) , 

FORCE_A, FORCE_B, FORCE_C, 
ERROR_l ) , 



or #10 

or_l (VOTE_ERROR, ERROR_0, ERROR_l , ERROR_2, ERROR_3 ) ; 



endmodule //* end module vote32bit_xcvr 
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c 



8 -BIT VOTER/ERROR DETECTOR 



UOTESBir 



A< 7. . 0> 0_ 


7. . 0> 
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Figure 49. 8-Bit Voter/Error Detector. 



//* File: voteSbit.v 

//* 

//^ Description: Verilog structural file for 8 bit majority voter and 

//* error detector using 8 votecell modules 

//^ 

//* Author: John C. Payne, Jr. 

//* Date: 10/06/98 



'timescale 1 ns /I ps 

//* Module: votecell 

//* 

//* Description: Verilog structural module for a one bit voter/error 

//■*^ detector. Votes 3 input bits to produce 1 output bit. FORCE_A, 

//* FORCE_B, Sc FORCE_C inputs can be used to disable voting and 

//* force data on A, B, or C through to the output. 

I !'k'k'k'k'k'k'k'k’k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k-k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k-k'k'k'k'i('k'k-j('k'k'k'k-k'k'k'k'k'k'k'k'k'k'k'k'k'k 

module votecell (IN_A, FORCE_A, IN_B, FORCE_B, IN_C, FORCE_C, MAJ_OUT, 
MAJ_ERROR) ; 



input IN_A, FORCE_A, IN_B, FORCE_B, IN_C, FORCE_C; 
output MAJ_OUT, MAJ_ERROR; 



not 

not_l (NOT_IN_A, IN_A) , 
not_2 (NOT_IN_B, IN_B) , 
not_3 {NOT_IN_C, IN_C) , 
not_4 {NOT_FORCE_A, FORCE_A) , 
not_5 {NOT_FORCE_B, FORCE_B) , 
not_6 {NOT_FORCE_C, FORCE_C) ; 



and 

and_l 

and_2 

and_3 

and_4 

and_5 

and_6 



(and_l_out, IN_A, 
( and_2_out , IN_B , 
( and_3_out , IN_C , 
(and_4_out, IN_A, 
NOT_FORCE_C) , 
(and_5_out, IN_A, 
NOT_FORCE_C) , 
(and_6_out, IN_B, 
NOT_FORCE_C) ; 



FORCE_A) , 

FORCE_B) , 

FORCE_C) , 

IN_B, NOT_FORCE_A, NOT_FORCE_B, 
IN_C, NOT_FORCE_A, NOT_FORCE_B, 
IN_C, NOT_FORCE_A, NOT_FORCE_B, 
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or #15 

or_l (MAJ^OUT, and_l_out, and_2_out, and_3_out, and_4_out, 
and_5_out/ and_6_out) ; 



and 

and_7 (and_7_out, NOT_IN_A, NOT_IN_B, IN_C, NOT_FORCE_A, 
NOT_FORCE_B, NOT_FORCE_C) . 

and_8 (and_8_out, NOT_IN_A, IN_B, NOT_IN_C, NOT_FORCE_A, 
NOT_FORCE_B, NOT_FORCE_C) , 

and_9 (and_9_out, NOT_IN_A. IN_B, IN_C, NOT_FORCE_A, NOT_FORCE_B, 
NOT__FORCE_C) , 

and_10 (and_10_out, IN_A, NOT_IN_B, NOT_IN_C. NOT_FORCE_A, 
NOT_FORCE_B, NOT_FORCE_C) , 

and_ll (and_ll_out, IN_A, NOT_IN_B, IN_C, NOT_FORCE_A, 
NOT_FORCE_B, NOT_FORCE_C) . 

and_12 (and_12_out, IN_A, IN_B, NOT_IN_C, NOT_FORCE_A, 
NOT_FORCE_B, NOT_FORCE_C) ; 



or #15 

or_2 (MAJ^ERROR, and_7_out, and_8_out, and_9_out, and_10_out, 
and_ll_out, and_12__out) ; 



endmodule //* end module votecell 



! !'k'k'k'if'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k't('k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k-k'k-k-k‘k'k'k'k-k'k't('tr'k 

//* Module: vote8bit 

//* 

//* Description: Verilog structural module for an 8 bit voter/error 

//* detector. Votes 24 input bits to produce 8 output bits. 

//* FORCE_A, FORCE_B, & FORCE_C inputs can be used to disable voting 

//* and force data on A[7:0], B[7:0], or C[7:0] through to the 

//* output. Uses eight votecell modules. This module drives the 

//* V0TE8BIT block in the Cadence Concept schematic. 

//* NOTE; Module name must match the Cadence Concept block name, but 
//* must be in lower case. Signal names of inout, input, and output 

//* lines and size (or bus width) must match the signal names in the 

//* Cadence Concept block. 

j I********************************************************************** 

module voteSbit (A, FORCE_A, B, FORCE_B, C, FORCE_C, VOTED_OUT, 
VOTE_ERROR) ; 

input [7:0] A, B, C; 
input FORCE_A, F0RCE_B, FORCE_C; 
output [7:0] VOTED_OUT ; 
output VOTE_ERROR; 

wire ERROR_0, ERROR_l, ERROR_2 , ERROR_3 , ERROR_4 , ERROR_5 , ERR0R_6 , 
ERR0R_7 ; 

votecell 

cello (A[0], FORCE_A, B[0], F0RCE_B, C[0], F0RCE_C, 

VOTED_OUT [ 0 ] , ERROR_0 ) , 



celll (A[l], FORCE_A, B[l], FORCE_B, C[l], FORCE_C, 
V0TED_0UT [ 1 ] , ERR0R_1 ) , 

cell2 (A[2], FORCE_A, B[2], FORCE_B, C[2], FORCE_C, 
VOTED_OUT [ 2 ] , ERROR_2 ) , 
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cell3 


(A[3], FORCE_A, B[3], FORCE_B, C[3], 
VOTED_OUT [ 3 ] , ERROR_3 ) , 


FORCE_C , 


cell4 


(A[4] , FORCE_A, B[4], FORCE_B, C[4], 
VOTED_OUT ( 4 ] , ERROR_4 ) , 


FORCE_C , 


cells 


(A[5], FORCE_A, B[5], FORCE_B, C[5], 
VOTED_OUT [ 5 ] , ERROR_5 ) , 


FORCE_C , 


cell6 


(A[6] , FORCE_A, B[6], FORCE_B, C[6], 
VOTED_OUT [ 6 ] , ERROR_6 ) , 


FORCE_C . 


cell? 


(A[7] , FORCE_A, B[7], FORCE_B, C[7], 
VOTED_OUT [ 7 ] , ERROR_7 ) ; 


FORCE_C , 


or #10 


or_l 


(VOTE_ERROR, ERROR_0, ERROR_l , ERROR. 
ERROR_5 , ERROR_6 , ERROR_7 ) ; 


2, ERROR_: 


endmodule 


II* end module voteSbit 





, ERR0R_4 , 
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D 



32 -BIT VOTER/ERROR DETECTOR 



U0TE32BIT 



fi<3i. . 0>0_ 


R<31. . 0> 


B< 3i . . 0>Q_ 


B<31. . 0> U0TED_0UT<3i. . 0> 


C<3i. . 0>©_ 


C<31. . 0> 


force:_A0_ 


rORCE_P 


force: _Bq_ 


rORCE.B UOTE_ERROR 


force:_C0_ 


rORCE«C 



UOTED_OUT< 3i . 



UOTE_ERROR 



0 > 



Figure 50. 32-Bit Voter/Error Detector. 



//* File; vote32bit.v 
//* 

//* Description: Verilog structural file for 32 bit majority voter and 

//* error detector using 4 voter_8bit modules 

//* 

//* Author: John C. Payne, Jr. 

//^ Date: 10/06/98 

'timescale 1 ns /I ps 

//* Module: vote32bit 

//* 

//* Description: Verilog structural module for a 32 bit voter/error 

//* detector. Votes 96 input bits to produce 32 output bits. 

//* FORCE_A, FORCE_B, & FORCE_C inputs can be used to disable voting 

//* and force data on A[31:0], B[31:0], or C[31:0] through to the 

//* output. Uses four vote8bit modules. This module drives the 

//* VOTE32BIT block in the Cadence Concept schematic. 

//* NOTE: Module name must match the Cadence Concept block name, but 

//* must be in lower case. Signal names of inout, input, and output 

//* lines and size (or bus width) must match the signal names in the 

//* Cadence Concept block. 

module vote32bit (A, FORCE_A, B, FORCE_B, C, FORCE_C, VOTED_OUT, 
VOTE_ERROR) ; 

input [31:0] A, B, C; 
input FORCE_A, FORCE_B, FORCE_C; 
output [31:0] VOTED_OUT; 
output VOTE_ERROR; 

wire ERROR_0, ERROR_l, ERROR_2 , ERR0R_3 ; 
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voteSbit 

voterO {A[31:24], FORCE_A, B[31:24], FORCE_B, C[31:24], FORCE_C, 
VOTED_OUT [31:24], ERROR_0 ) , 

voterl {A[23:16], FORCE_A, B[23;16], FORCE_B, C[23:16], FORCE_C, 
VOTED_OUT [23:16], ERROR_l ) , 

VOter2 {A[15:8], FORCE_A, B[15:8], FORCE_B, C[15:8], FORCE_C, 
VOTED_OUT [15:8], ERROR_2 ) , 

vocer3 {A[7:0], FORCE_A, B[7:0], FORCE_B, C[7:0], FORCE_C, 
VOTED_OUT [7:0], ERROR_3 ) ; 

or #10 

or_l (VOTE_ERROR, ERROR_0 , ERROR_l , ERROR_2 , ERROR_3 ) ; 
endmodule //* end module vote32bit 
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E 



MEMORY /ADDRESS DECODER 



MEM_DECODER 



A< 3i. . i7> 



G — 





RRMCS)K 


A<31. . 1T> 


EPROMCS>k 




INTCSjk 



-O 



RAMCS)k 

EPROMCS>k 

INTCS>K 



Figure 51. Memory /Address Decoder. 



//* File: mem_decoder . V 

//* 

//* Description: Verilog structural file for memory decoder to 

//* generate various chip selects. 

//* 

//* Author: John C. Payne, Jr. 

//* Date: 10/06/98 

! I^fif-kitif’k'k'k'k'k'k'kit'kif'k'k'k'k'k'kif'k'k'k’k'k'k'k'k'k'k'k'k'k’k'k'k'k'k'k'k'k'k'if'k'k’k'k’k'k'k'if'k'k'kifif'k'k'kit'k’k'k’k'k'if'k'k 



'timescale 1 ns / 1 ps 



//* Module: mem_decoder 

//* 

//* Description: Verilog behavioral module for a memory decoder. Uses 

//* input A [31: 17] to generate three active low chip select outputs. 

//* This module drives the MEM_DECODER block in the Cadence Concept 

//* schematic. 

//* NOTE: Module name must match the Cadence Concept block name, but 

//* must be in lower case. Signal names of inout, input, and output 

//* lines and size (or bus width) must match the signal names in the 

//* Cadence Concept block. 

module mem_decoder (A, RAMCS_N, EPR0MCS_N, INTCS_N) ; 



input [31:17] A; 

output RAMCS_N, EPR0MCS_N, INTCS^N; 
wire RAMCS^N, EPROMCS^N, INTCS^N; 



//* 

//* 

//* 



RAM 

EPROM 

INT 



00000000 to 0007FFFF 
IFCOOOOO to IFCOxxxx 

1F800000 "Dummy Address to Disable Vote Error Interrupts 
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assign #45 



RAMCS^N = 


{ IA[31] 




!A[30] 


Sc Sc 


!A[29] 


Sc Sc 


1A[28] 


Sc Sc 


//* 


0 




!A[27] 


ScSc 


!A[26] 


Sc Sc 


!A[25] 


Sc Sc 


!A[24] 


Sc Sc 


//* 


0 




!A[23] 


ScEc 


!A[22] 


Sc Sc 


!A[21] 


Sc Sc 


!A[20] 


Sc Sc 


//■* 


0 




!A[19] ) ?0: 


1; 












//* 


7 


assign #45 






















EPROMCS_N = 


( !A[31] 


Sc8c 


!A[30] 


Sc Sc 


!A[29] 


Sc Sc 


A[28] 


Sc Sc 


/ r 


1 




A[27] 


ScSc 


A[26] 


Sc Sc 


A[25] 


Sc Sc 


A[24] 


Sc Sc 


//* 


F 




A[23] 


ScSc 


A[22] 


Sc Sc 


!A[21] 


Sc Sc 


iA[20] 


Sc Sc 


//* 


c 




!A[19] 


ScSc 


!A[18] 


Sc Sc 


IA[17] ) 


?0 : 






//* 


0 


assign #45 






















INTCS^N = 


( 1A[31] 


ScSc 


!A[30] 


Sc Sc 


1A[29] 


Sc Sc 


A[28] 


Sc Sc 


in 


1 




A[27] 


ScSc 


A[26] 


Sc Sc 


A[25] 


Sc Sc 


A[24] 


Sc Sc 


//* 


F 




A[23] 


Sc Sc 


!A[22] 


Sc Sc 


!A[21] 


Sc Sc 


!A[20] 


Sc Sc 


//* 


8 




!A[19] 


Sc Sc 


1A[18] 


Sc Sc 


IA[17] ) ?0: 


1; 




//■^ 


0 


endmodule //* end 


module 


mem 


^decoder 
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F 



MEMORY /ERROR CONTROLLER 



MEM^CONT 



UOTRO^N/ 



UOTBURST^N/ 



INTCS^N/ 



CONTERRc 



USEEI FO(^ 



SYSCLK:+: 


RESET Jk 


ENSTARTjk 


UOTRQjk 


CYCEND?k 


UOTURjk 


RDCENjk 


U0TBURST.1C 


ACKjk 


RftMCS?k 


BUSERRORjk 


EPROMCSjk 


ADDRTOrirOjk 


INTCSjk 


□ATATOnrO?k 


RDDRERR 


C0NTT0riF0:4< 


DATAERR 


FIFOUEjk 
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usEFi ro 


UOTERRORINTjk 



^UOTERROR-INT^N 



Figure 52. Memory/Error Controller. 



// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 



* File: mem^cont.v 

★ 

* Description: Verilog behavioral file for memory/error controller 

* to control timing cycles of various bus transactions. 

* 

* Reference: (1) IDT RISC Microprocessor Application Guide, 

* Application Note AN-86, IDT79R3051 System Design 

* Example 

* Author: John C. Payne, Jr. 

* Date: 11/3/98 



'timescale 1 ns /I ps 



//* Module: mem_cont 

//* 

//* Description: Verilog behavioral module for the memory/ error 

//* controller. Produces READ, WRITE, and BUS ERROR acknowledge 
//* controls (RDCEN_N, ACK_N, BUSERROR_N) based on a 5 bit counter 
//* and cycle end stall cycle (wait state) equations. 

//* Also produces an interrupt if there is a vote error detected on 

//* the ADDRERR, CONTERR, or DATAERR inputs. The ADDRERR, CONTERR, 

//* and DATAERR inputs are saved at specified values of the counter, 
//* and an error interrupt is generated only at the end of the 

//* current cycle, so that the current cycle is allowed to finish. 

//* If INTCS_N goes low during a dummy write to that address, this 

//* signals the beginning of the interrupt handler routine and 
//* vote error interrupts are disabled until INTCS_N goes low again, 
//* which signals the end of the interrupt handler routine. 

//* This module also controls the three lines ADDRTOFIFO_N, 

//* CONTTOFIFO_N, and DATATOFIFO_N which send the appropriate 
//* information to the dedicated FIFOs. These three lines are 
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//* active low enable lines which allow, through the use of 32-bit 

//* tri-state buffers, the ADDRESS, CONTROL, and DATA information 

//* from the processor to be multiplexed onto a single 32-bit bus 

//* which is the input bus for each dedicated FIFO. The FIFOWE_N 

//* line signals a write to the FIFOs at the appropriate time within 
//* a bus cycle based on the 5-bit counter. 

//* This module drives the MEM_CONT block in the Cadence Concept 

//* schematic. 

//* NOTE: Module name must match the Cadence Concept block name, but 

//* must be in lower case. Signal names of inout, input, and output 

//* lines and size (or bus width) must match the signal names in the 

//* Cadence Concept block. 

//* 

//* Reference: (1) IDT RISC Microprocessor Application Guide, 

//* Application Note AN-86, IDT79R3051 System Design 

//* Example 

//* 

module mem_cont (SYSCLK_N, RESET_N, VOTRD_N, VOTWR_N, VOTBURST_N, 
RAMCS_N, EPROMCS_N, INTCS_N, USEFIFO, DATAERR, 

ADDRERR, CONTERR, ENSTART_N, CYCEND_N, 

RDCEN_N, ACK_N, BUSERROR^N, ADDRTOFIFO_N, 

DATATOFIFO_N , CONTTOF IFO_N , FI FOWE_N , 

VOTERROR_INT_N) ; 



input SYSCLK_N, 
RESET_N, 
VOTRD^N, 
VOTWR_N, 
VOTBURST_N, 
RAMCS_N, 
EPROMCS^N, 
INTCS_N, 
USEFIFO, 
DATAERR, 
ADDRERR, 
CONTERR; 



//* System clock from R3081 

//* Reset from MEMEN module 

//* Voted read from R3081 

//* Voted write from R3081 

//* Voted burst from R3081 

//* RAM chip select from memory decoder 

//* EPROM chip select from memory decoder 

//* INT chip select from memory decoder 

//* Set High (pull up) to Write to FIFOs 

//* Data Vote Error from 32-bit Data Voter 

//* Address Vote Error from 32-bit Address Voter 

//* Control Vote Error from 8-bit Control Voter 



output ENSTART_N, //* 

CYCEND_N, //* 

RDCEN_N, //* 

ack_n, • //* 

BUSERROR_N, //* 

ADDRTOFIFO_N, //* 

DATATOFIFO_N, //* 

CONTTOFIFO_N, //* 

FIFOWE_N, //* 



VOTERROR_INT_N ; / / * 



Read/write output enable start 
Cyle end (composite ACK) 

R3081 read buffer clock enable 
R3081 acknowledge 
R3081 bus error 

Address To FIFO to Address Buffers 
Data To FIFO to Data Buffers 
Control To FIFO to Control Buffers 
FIFO Write Enable 
Interrupt Sent to R3081 



wire ENSTART_N, CYCEND_N, RDCEN_N, ACK_N, BUSERROR_N, 
ADDRTOFIFO_N, DATATOFIFO_N, CONTTOFIFO_N , 

’ . FIFOWE_N, VOTERROR_INT_N; 



reg [4:0] counter; 
reg voteErrorIntEn; 
wire voteError; 

reg saveErrorl, saveError2 , saveError3 , saveError4; 
reg voteErrorIntValueToGo ; 
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/'* At the positive edge of the reset input line, RESET_N, ensure 
//* vote error interrupts are enabled, the interrupt line is HIGH, 

//* and the saved error flags are initialized to indicated no error 

//* has been detected. 

always 

@(posedge RESET_N) 
begin 

voteErrorIntEn =1; , 

voteErrorIntValueToGo = 1; 

saveErrorl = 0; 

saveError2 = 0; 

saveErrorl = 0 ; 

saveError4 = 0 ; 

end 

//* At each positive edge of the system reference clock generated 
//* by the R3 081, reset the counter if RESET_N or CYCEND_N goes lov;. 
//* Increment the counter if V0TRD_N or V0TWR_N is low. Save the 
//* error flag at the four different counter values, so that the 
//* cycle is allowed to finish. The use of four different saved 
//* values allows a single READ or WRITE to finish as well as a 
//* BURST READ to finish. If the current transaction is a BURST 
//* READ, then an ADDRERR, CONTERR, or DATAERR is sampled four times, 
always 

@ (posedge SYSCLK_N) 
begin 

if (!RESET_N || !CYCEND_N) 
counter = 0; 

else if ( !VOTRD_N || iVOTWR_N) 
counter = counter + 1; 

if (RESET_N ScSc CYCEND^N && (counter == 5'h05)) 
saveErrorl = voteError; 

else if (RESET_N && CYCEND_N && (counter == 5'h09)) 
saveError2 = voteError; 

else if (RESET^N && CYCEND_N && (counter == 5'hOB)) 
saveErrorl = voteError; 

else if (RESET_N && CYCEND_N && (counter == 5'hl7)) 
saveError4 = voteError; 

//* If at the end of a cycle, and one of the saved errors 
//* indicates an error occurred, then generate an interrupt 
//* only if vote error interrupts are currently enabled, 
if (RESET_N ScSc !CYCEND_N && voteErrorIntEn && 

(saveErrorl | | saveError2 | | saveErrorl | | saveError4)) 
voteErrorIntValueToGo = 0; 

end 

//* Watch for negative edge of INTCS_N, and disable/reenable vote 

//* error interrupts. 

always 

@ (negedge INTCS_N) 
begin 

voteErrorIntEn = --voteErrorIntEn; 

VoteErrorIntValueToGo = 1; 
saveErrorl = 0; 
saveError2 = 0; 
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saveError3 = 0 ; 
saveError4 = 0 ; 

end 

//* Update internal voteError flag 

assign #30 voteError = (ADDRERR || DATAERR || CONTERR) ?1 : 0 ; 

//* Update VOTERROR_INT_N output line 

assign #30 VOTERROR_INT_N = voteErrorIntValueToGo ; 

//* Update ENSTART_N output line 

assign #30 ENSTART_N = (RESET_N && (counter >= 1) &S= CYCEND_N) ?0 : 1 ; 

//* Update CYCEND_N output line 
assign #30 CYCEND_N = 

(RESET_N && CYCEND_N && ( 

(!RAMCS_N && (counter == 5'h05) && !VOTRD_N && VOTBURST_N) 

II (!RAMCS_N && (counter == 5'hl7) && !VOTRD_N && !VOTBURST_N) 

II (!RAMCS_N && (counter == 5'h06) && !VOTWR_N) 

I I (!EPROMCS_N && (counter == 5'h05) &&: !VOTRD_N && VOTBURST_N) 

II (!EPROMCS_N S=& (counter == 5'hl7) && !VOTRD_N && !VOTBURST_N) 
II (!INTCS_N && (counter == 5'h06) && !VOTWR_N) 

I I (counter == 8'hlF) 

) ) ? 0 : 1 ; 



//* Update RDCEN_N output line 
assign #30 RDCEN_N = 

(RESET_N && CYCEND_N && ( 
(!RAMCS_N S=& !VOTRD_N && 

( 

(counter 

II ( !VOTBURST_N && (counter 

I I ( !VOTBURST_N &S= (counter 

II ( !VOTBURST_N &Sc (counter 

) 

) 

I I (!EPROMCS_N && !VOTRD_N && 

( 

(counter 

II ( !VOTBURST_N && (counter 

I I ( !VOTBURST_N && (counter 

II ( !VOTBURST_N && (counter 

) 

) 

) ) 70:1; 



5'h03) 
5'h09) ) 
5'hOF) ) 
5'hl5)) 



5'h03) 
5'h09) ) 
5 'hOF) ) 
5'hl5) ) 



//* Update ACK_N output line 

assign #30 ACK_N = (RESET_N && CYCEND_N && 

( 

(!RAMCS_N && 1V0TWR_N && 
(counter == 5'h06) 

) 

I I ( !RAMCS_N && !VOTRD_N && 
(counter == 5'h03) 

) 

I I (!EPROMCS_N && !VOTRD_N && 
(counter == 5'h03) 

) 
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(!INTCS_N && !VOTWR_N Sc& 
(counter == 5'h06) 

) 



))? 0 : 1 ; 

//* Update BUSERROR_N output line 
assign #30 BUSERROR_N = 

(RESET_N &Sc CYCEND_N && (counter = = 

//■» Update ADDRT0FIF0_N output line 
assign #30 ADDRTOFIFO_N = 

(RESET_N ScSc CYCEND_N && USEFIFO && 

( 



5'hlF) ) ?0:1; 





(counter 


== 


5'hOl) 


(lEPROMCS N ScA iVOTRD. 
( 

( ! VOTBURST_N && 


_N ScSc 






(counter 




5 'h07) ) 


1 1 ( !VOTBURST_N && 


( counter 


== 


5 'hOD) ) 


1 1 ( !VOTBURST_N && 

) 


(counter 


= — 


5'hl3) ) 


) 

(!RAMCS_N Sc Sc !VOTRD_N 


ScSc 






{ 

(!VOTBURST_N && 


( counter 


== 


5'h07) ) 


1 1 ( !VOTBURST_N ScSc 


(counter 


== 


5'hOD) ) 


II ( ! VOTBURST_N ScSc 


( counter 


== 


5'hl3) ) 



) 

)? 0 : 1 ; 

//* Update CONTTOFIFO_N output line 
assign #30 CONTTOFIFO_N = 

(RESET_N && CYCEND_N && USEFIFO && 



( 



II ( ! EPROMCS_N ScSc 
( 



(counter 
!VOTRD_N && 



== 5'h03) 



( !VOTBURST_N 


ScSc 


(counter 


== 


5'h09) ) 


II ( ! VOTBURST_N 


ScSc 


(counter 


= = 


5'hOF) ) 


1 1 ( !VOTBURST_N 

) 


ScSc 


(counter 




5'hl5) ) 


RAMCS_N ScSc !VOTRD_N 


ScSc 






V 

( !VOTBURST_N 


ScSc 


(counter 


= — 


5^h09) ) 


II ( ! VOTBURST_N 


ScSc 


(counter 


== 


5'hOF) ) 


II (!VOTBURST_N 


ScSc 


(counter 


== 


5'hl5) ) 



) 

?0 : 1 ; 
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//» Update DATATOFIFO_N output line 
assign #30 DATATOFIFO_N = 

(RESET_N && CYCEND_N && USEF 

( 



{ !VOTBURST_N && 
( !VOTBURST_N && 
( !VOTBURST_N && 



) 

(!RAMCS_N && !V0TRD_N && 



( 



( !VOTBURST_N && 
( ! VOTBURST_N && 
(!VOTBURST_N && 



) ScSc. 




{counter == 


5 'h05) 


.N ScSc 




(counter == 


5'hOB) ) 


(counter == 


5'hll) ) 


(counter == 


5'hl7) ) 


Sc Sc 




(counter == 


5 'hOB) ) 


(counter == 


5'hll) ) 


(counter == 


5'hl7) ) 



) 

) ? 0 : 1 ; 



//* Update FIF0WE_N output line 
assign #30 FIF0WE_N = 

(RESET_N && CYCEND_N && USEFIFO S=& 

( 



(counter == 5'hOl) 
(counter == 5'h03) 
(counter == 5'h05) 



VOTBURST. 


_N 


Sc Sc 


IVOTRD. 


_N 


Sc Sc 


(counter 


= = 


5'h07) ) 


VOTBURST. 


_N 


Sc Sc 


IVOTRD. 


_N 


Sc Sc 


(counter 


== 


5'h09) ) 


VOTBURST. 


_N 


Sc Sc 


! VOTRD. 


_N 


Sc Sc 


(counter 


== 


5'hOB) ) 


VOTBURST. 


-N 


Sc Sc 


IVOTRD. 


-N 


Sc Sc 


(counter 


= = 


5'hOD) ) 


VOTBURST. 


_N 


Sc Sc 


IVOTRD. 


_N 


Sc Sc 


(counter 


== 


5 'hOF) ) 


VOTBURST. 


_N 


Sc Sc 


IVOTRD. 


-N 


Sc Sc 


( counter 


= = 


5'hll) ) 


VOTBURST. 


-N 


Sc Sc 


IVOTRD. 


_N 


Sc Sc 


( counter 


= = 


5'hl3) ) 


VOTBURST. 


_N 


Sc Sc 


IVOTRD. 


-N 


Sc Sc 


(counter 


== 


5'hl5) ) 


VOTBURST. 


_N 


Sc Sc 


IVOTRD. 


_N 


Sc Sc 


(counter 


== 


5'hl7)) 



) 



endmodule //* end module mem_cont 
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MEMORY READ /WRITE ENABLE CONTROLLER 



MEM_EN 



UOTRD_N( 

OOTWR^N( 

:nstrrt^n ( 

CYCEND_N ( 
BEN0( 
BEN1( 
BEN2r 



SYSCLK>K 


RESET>K 


PWRRESET>K 


00TRD>K 


WRDRTREN>K 


U0TNR>K 


WREN_R>K 


ENSTRRT>K 


NREN_B>K 


CYCEND>K 


NREN_C>K 


BEN0 


NREN_D>K 


BENI 


RDEN>K 


BEN2 


RDDRTRENX< 


BEN3 





-0RESET-.N 



Figure 53. Memory Read/Write Enable Controller. 



//* File: mem_en.v 

//* 

//* Description: Verilog behavioral file for generating memory read 

//* and write enable signals. 

//* 

//* Reference: (1) IDT RISC Microprocessor Application Guide, 

//* Application Note AN-86, IDT79R3051 System Design 

//* Example 

//* 

//* Author: John C. Payne, Jr. 

//* Date: 11/1/98 

'timescale 1 ns /I ps 



//* Module: mem_cont 

//* 

//* Description: Verilog behavioral module for generating the read 

//* and write enables for the memory controls. 

//* This module drives the MEM_EN block in the Cadence Concept 
//* schematic. 

//* NOTE: Module name must match the Cadence Concept block name, but 

//* must be in lower case. Signal names of inout, input, and output 

//* lines and size {or bus width) must match the signal names in the 

//* Cadence Concept block. 

//* 

//* Reference: (1) IDT RISC Microprocessor Application Guide, 

//* Application Note AN-86, IDT79R3051 System Design 

//* Example 

//* 
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module mem_en {SYSCLK_N, PWRRESET.N, VOTRD^N, VOTWR_N, ENSTART_N, 
CYCEND_N, BENO, BENI, BEN2 , BEN3 , RESET_N, WREN_N, 
WRDATAEN^N, WREN_NA, WREN^NB, WREN_NC , WREN_ND, RDEN_N, 
RDDATAEN_N) ; 



input SYSCLK^N, //* 

PWRRESET_N, //* 

VOTRD_N, //* 

VOTWR_N, //* 

ENSTART_N, //* 

CYCEND^N, //* 

BENO , / / * 

BENI , / / * 

BEN2 , / / * 

BEN3 ; / / * 



System clock from R3081 

Power (Global) reset 

Voted read from R3081 

Voted write from R3081 

Enable start from memory controller 

Cycle end from memory controller 

Byte 0 enable (active low) from R3081 

Byte 1 enable (active low) from R3081 

Byte 2 enable (active low) from R3081 

Byte 3 enable (active low) from R3081 



(ADDR[ 

(ADDR[ 

(ADDR[ 

(ADDR[ 



output RESET_N, 
WREN_N, 
WRDATAEN_N, 
WREN_NA, 
WREN_NB, 
WREN^NC , 
WREN^ND, 
RDEN_N, 
RDDATAEN_N; 



//* Synchronzied reset line to rest of board 
//* Not used 

//* Write data xcvr enable 

//* Write enable for byte 0 

//* Write enable for byte 1 

//* Write enable for byte 2 

//* Write enable for byte 3 

//* Read output enable (for words) 

//* Read data xcvr enable 



wire RESET.N, WREN_N, WRDATAEN_N, WREN_NA, WREN_NB, WREN_NC , WREN_ND, 
RDEN_N , RDDATAEN_N ; 



assign #30 WREN_NA = 
i (RESET^N ScEc 

(!V0TWR_N ScSc !BEN0 ScSc ! ENSTART_N &Sc CYCE1TO_N) 

) ; 

assign #30 WREN_NB = 

! (RESET_N ScSc 

( !V0TWR_N ScSc !BEN1 ScSc ! ENSTART_N &Sc CYCEND_N) 

) ; 

assign #30 WREN_NC = 

! (RESET_N ScSc 

(!V0TWR_N ScSc !BEN2 ScSc ! ENSTART_N && CYCEND_N) 

) ; 

assign #30 WREN^ND = 

! (RESET_N ScSc 

(!VOTWR_N ScSc 1BEN3 ScSc ! ENSTART_N ScSc CYCEND_N) 

) ; 

assign #30 WREN_N = 

! (RESET_N ScSc 

((!V0TWR_N ScSc CYCEND_N) || ( !WREN_N ScSc !CYCEND_N)) 

) ; 
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assign #30 WRDATAEN_N = 

! (RESET_N && 

( ( !VOTWR_N && !ENSTART_N) | | 

( !WRDATAEN_N && ( ! ENSTART_N || !CYCEND_N)) 

) 

) ; 

assign #30 RDEN_N = 

! (RESET_N && 

( !VOTRD_N && !ENSTART_N && CYCEND_N) 

) ; 

assign #30 RDDATAEN_N = 

! (RESET_N && 

( !VOTRD_N && !ENSTART_N && CYCEND_N) 

) ; 

assign #30 RESET_N = ! ( ! PWRRESET_N) ; 
endmodule //* end module mem_en 
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16-BIT NON-INVERTING TRI-STATE BUFFER 



BUFF_16BIT 



IN0 


IN0 


OUT0 


-0OUT0 


INI 


INI 


OUTl 


^OUTl 


IN2q_ 


IN2 


0UT2 


_qOUT2 


IN3(^ 


IN3 


0UT3 


-qOUT3 


IN4 0^ 


IN4 


0UT4 


-qOUT4 


IN5 0. 


INS 


OUTS 


-0OUT5 


IN6 


INS 


OUTS 


^OUTS 


IN7 


IN7 


0UT7 


0UT7 


IN8 


INS 


OUTS 


OUTS 


IN9 


IN9 


0UT9 


_rOUT9 


N10-^ 


IN10 


OUT10 


^OUT10 


Nil ^ 


INll 


OUTll 


OUT 11 


N12-_^ 


IN12 


0UT12 


^,0UT12 


Nl3o- 


IN13 


0UT13 


-_^0UT13 


N140. 


IN14 


0UT14 


-0OUT14 


N150. 


INiS 0UT15 

OE>l< 


^OUTIS 



OE_N 



Figure 54. 16-Bit Non- Inverting Tri-State Buffer. 



//* File; buff_16bit.v 
//* 

//* Description: Verilog structural file for 16 bit tri-state 

//* non-inverting buffer. 

//* 

//* Author: John C. Payne, Jr. 

//* Date: 11/16/98 

j 

'timescale 1 ns /I ps 



I |•k•k•k^k^k•k^k^k'k^k'k^k•k'k'k^k'k^k'k'k•k^k'k'k^k^k^k'k'k•k•k^k'k'k^k•k•k•k•k•k^k'k'k•k•k•k^k'k•k•k•k'k'k•k•k^k•k^k•k'k•k•k^k^k^k'k^k'k^k•k 

//* Module: interface 

//* 

//* Description: Verilog structural module for simulating a 16-bit 

//* tri-state non-inverting buffer. 

//* This module drives the BUFF_16BIT block in the Cadence Concept 
//* schematic. 

//* NOTE: Module name must match the Cadence Concept block name, but 

//* must be in lower case. Signal names of inout, input, and output 

//* lines and size (or bus width) must match the signal names in the 

//* Cadence Concept block. 

module buff_16bit (INO, INI, IN2, IN3 , IN4, INS, IN6, IN7, 

INS, INS, INIO, INll, IN12, IN13 , IN14, INIS, 

ONTO, OUTl, 0UT2, 0UT3 , 0UT4, OUTS, 0UT6 , 0UT7 , 

OUTS, OUTS, OUTIO, OUTll, 0UT12 , 0UT13, 0UT14 , OUTIS, 
OE_N) ; 
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input INO, INI, IN2, IN3 , IN4, INS, IN6, IN7, 

INS, IN9, INIO, INll, IN12, IN13, IN14, INIS; 
output OUTO, OUTl, OUT2, OUT3 , OUT4 , OUTS, OUT6 , OUT7 , 

OUTS, OUT9, OUTIO, OUTll, OUT12, OUT13, OUT14, OUTIS; 
input OE_N; 



bufifO #(0:1S:30, 0:1S:30, 0:15:30) 
buff_0 (OUTO, INO, OE_N) , 
buff_l (OUTl, INI, OE_N) , 
buff_2 (OUT2, IN2, OE_N) , 
buff_3 (OUT3, IN3, OE_N) , 
buff_4 (OUT4, IN4, OE_N) , 
buff_5 (OUTS, INS, OE_N) , 
buff_6 (OUT6, IN6, OE_N) , 
buff_7 (OUT7, IN7, OE_N) , 
buff_S (OUTS, INS, OE_N) , 
buff_9 (OUT9, IN9, OE_N) , 
buff_10 (OUTIO, INIO, OE_N) , 
buff_ll (OUTll, INll, OE_N) , 
buff_12 (OUT12, IN12, OE_N) , 
buff_13 (OUT13, IN13, OE_N) , 
buff_14 (OUT14, 1N14, OE_N) , 
buff_15 (OUTIS, INIS, OE_N) ; 



endmodule //* end module buff_16bit 
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EPROM 





EPROM 


A0q^ 


A< 0> DATA< 31. . 0> 


Al 0.. 


A< 1 > 


A14_2< 14. . 2>q_ 


A< 14. . 2> 


OUTPUTENABLE_N 


OE^ 


CHIPSELECT-N q_ 


CS:*< 



0> —qDOTPk 31. . 0> 



Figure 55. EPROM. 



//* File: eprom.v 

//* 

//* Description: Verilog behavioral file for an EPROM. 

//* 

/ Author: John C. Payne, Jr. 

//* Date: 10/28/98 

j j-k'if'k-k'k'k'k'k'k'k'ktf-k'k-ii'k-k'k'if'k-kit'k'k-if'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k-k'k-k'k'k'k-k'k'k-k'k'k'k'k-k'k'k'k-k'k'k-k'k-k'ktt'k'k-it 

'timescale 1 ns /I ps 

//* Define how many entries are in the data file for internal memory 
//* storage. 

'define EPROM_ENTRIES 48 

//* Module: eprom 

/ /-^ 

//* Description: Verilog behavioral module for simulating an EPROM, 

//^ Although because of the number of address lines, it is capable of 

//* being 128k, it has been limited to 48 entries to reduce data 

//* entry for simulation purposes. The memory data and intialized 

//* the data file EPROM. data. 

//* This module drives the EPROM block in the Cadence Concept 
//* schematic. 

//* NOTE: Module name must match the Cadence Concept block name, but 

//* must be in lower case. Signal names of inout, input, and output 

//* lines and size (or bus width) must match the signal names in the 

//* Cadence Concept block. 

Ijif'kiKif'k'k-k'k'k-k-k'k'k-k-k'k'lf'k-k-k-k'k-k'k-k-k-k'k-k'k'kic'k'k-k’k-k'k'k'k-k-k-k'k-k'k'k'k'k'k-k'k'k-k-k'k'k-ir'k'k'k-if'k'k'k'k'k'k'k'k 

module eprom {AO, Al, A14_2 , OUTPUTENABLE_N, CHIPSELECT_N, DATA) ; 

//* EPROM Maximum Access Times *// 
parameter 

CY27C256_max_access = 45; 

//* Module input and output lines 
input AO , 

Al; 

input [14:2] A14_2; 
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input OUTPUTENABLE^N, 

CHIPSELECT^N; 
output [31:0] DATA; 

//* Internal variables (line enables) 

wire [14:0] combined_address ; 

reg [31:0] memory [ 0 :(' EPROM_ENTRIES - 1)]; 

//* Intialize internal memory from data file 
initial 
begin 

$readmemh{ "EPROM, data" , memory) ; 

end 

//* Combine input lines into single address 
assign combined_address [ 0 ] = AO ; 
assign combined_address [ 1] = Al; 
assign combined_address [ 14 : 2 ] = A14_2; 

//* Drive data bus with data from EPROM at combined address if 
//* OUTPUTENABLE_N and CHIPSELECT_N are both low. Drive to 
//* high impedance otherwise, 
assign # (CY27C256_max_access) DATA = 

( ! OUTPUTENABLE_N ScSc 

!CHIPSELECT_N) ?memory [ combined_address ] : 'bz; 
endmodule 



y/ / **★★★★★*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★*★★★*★★★★★★★★*★★*★★*★★★*★*★★★★*★★ 

//* File: EPROM. data 

//* 

//* Description: Capable of being 128K EPROM Memory File 
//* 17 address lines (A[16] - A[0]) = 

//* 131072 lines of 32-bit data/instructions allowed 

//* Only 48 entries have been supplied to reduce data entry for 
//* simulation purposes. 

//* 

//* Author: John C. Payne, Jr. 

I Date: 10/28/98 



00000000 

00000001 

00000002 

00000003 

00000004 

00000005 

00000006 

00000007 

00000008 

00000009 

OOOOOOOA 

OOOOOOOB 

oooooooc 

OOOOOOOD 

OOOOOOOE 

OOOOOOOF 

00000010 



//* ADDRESS 
//* OOOOOh 



//* 00007h 



//* OOOOFh 
//* OOOlOh 
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00000011 
00000012 
00000013 
00000014 
00000015 
00000016 
00000017 / 

00000018 
00000019 
OOOOOOIA 
OOOOOOIB 
OOOOOOIC 
OOOOOOID 
OOOOOOIE 
OOOOOOIF / 
00000020 / 
00000021 
00000022 
00000023 
00000024 
00000025 
00000026 
00000027 I 
00000028 
00000029 
0000002A 
0000002B 
0000002C 
0000002D 
0000002E 
0000002F / 



/* 00017h 



/* OOOlFh 
/* 00020h 



/* 00027h 



/* 0002Fh 



J 



SYSTEM INTERFACE 
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FIF0B0UT<31. . 0> 
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B_dE_N 
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FIFORD_N 



Figure 56. System Interface. 



//* File: interface. V 

//* 

//* Description: Verilog behavioral file for simulating the 

1 1 * interface portion of the TMR testbed. 

//* 

//* Author: John C. Payne, Jr. 

//* Date: 11/15/98 

j ^^★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★^ 

'timescale 1 ns /I ps 

'define HIGH 1 

'define LOW 0 



//* Module: interface 

//* 

//* Description: Verilog behavioral module for simulating the 

//* interface of the TMR Testbed which removes the information from 

//* the three FIFOs dedicated to the three microprocessors. 

//* The data that is read from each FIFO is formatted and written to 
//* text trace file ' TMR_trace . out ' . If the file doesn't exist, it 

//* is created in the current working directory. If the file already 

//* exists, it is emptied and overwritten. 

//* This module drives the INTERFACE block in the Cadence Concept 
//* schematic. 

//* NOTE: Module name must match the Cadence Concept block name, but 

//* must be in lower case. Signal names of inout, input, and output 

//* lines and size {or bus width) must match the signal names in the 

//* Cadence Concept block. 

/^******************************************** ****************. ********* 
module interface (FIFOAOUT, FIFOBOUT, FIFOCOUT, EF_A1_N, EF_A2_N, 

EF_B1_N, EF_B2_N, EF_C1_N, EF_C2_N, READCLK, 

A_OE_N, B_OE_N, C_OE_N, FIFORD_N) ; 
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//* Module input and output lines 
input [31:0] FIFOAOUT. 

FIFOBOUT, 

FIFOCOUT; 

input EF_A1_N, EF_A2__N, 

EF_B1_N, EF_B2_N, 
EF_C1_N. EF_C2_N; 

output READCLK, 

A_OE_N, 

B_OE_N, 

C_OE_N. 

FIFORD_N; 



reg READCLK; 
wire FIFORD_N; 

wire f ifoAEmpty_N, f if oBEmpty_N, f if oCEmpty_N; 
wire A_OE_N, B_OE_N, C_OE_N; 
reg [31:0] fileHandle; 

reg aOEenable, bOEenable, cOEenable, f ifoRdEnable; 

reg [31:0] Adata, Bdata, Cdata, saveAdata, saveBdata, saveCdata; 

initial 

begin 

READCLK = 'LOW; 
f ifoRdEnable = 'LOW; 
aOEenable = 'LOW; 
bOEenable = 'LOW; 
cOEenable = 'LOW; 

fileHandle = $ f open ( "TMR_trace . out " ) ; 

$fdisplay ( fileHandle, '' CPU A CPU B 

CPU C" ) ; 

$fdisplay ( fileHandle, 

II — — ———— — — — — — — ————————————————————— — —————————————— " j . 

end 

//* Control FIFO interface clock 
always 

#12.5 READCLK = -READCLK; 

//* Composite FIFO empty flags. If not empty, signals will be high, 
assign #30 fifoAEmpty_N = (EF_A1_N ScSc EF_A2_N) ?1 : 0 ; 

assign #30 fifoBEmpty^N = (EF_B1_N ScSc EF_B2_N) ?1 : 0 ; 

assign #30 fifoCEmpty_N = (EF_C1_N ScSc EF_C2_N) ?1 : 0 ; 

assign FIFORD_N = ( f if oRdEnable) ?0 : 1 ; 

assign A_OE_N = (aOEenable ) ?0 : 1 ; 
assign B_OE_N = (bOEenable) ?0 : 1 ; 
assign C_OE_N = (cOEenable) ?0 : 1 ; 

always 

begin 

wait ( ( f if oAEmpty_N == 'HIGH) EcSc ( f if oBEmpty_N == 'HIGH) ScSc 
( f ifoCEmpty_N == 'HIGH)) 



151 



begin 

//* Read FIFO A -- should be address from CPU A 
@{negedge READCLK) 
begin 
#5; 

fifoRdEnable = 'HIGH; 
aOEenable = 'HIGH; 

@{posedge READCLK) 
begin 
# 10 ; 

Adata[31:0] = FIFOAOUT[31:0]; 
fifoRdEnable = 'LOW; 
aOEenable = 'LOW; 

end 

end 

//* Read FIFO B should be address from CPU B 
@{negedge READCLK) 
begin 
#5; 

fifoRdEnable = 'HIGH; 
bOEenable = 'HIGH; 

@(posedge READCLK) 
begin 
# 10 ; 

Bdata[31:0] = FIFOBOUT [ 3 1 : 0 ] ; 
fifoRdEnable = 'LOW; 
bOEenable = 'LOW; 

end 

end 



//* Read FIFO C -- should be address from CPU C 
(3(negedge READCLK) 
begin 
#5; 

fifoRdEnable = 'HIGH; 
cOEenable = 'HIGH; 

@(posedge READCLK) 
begin 
# 10 ; 

Cdata[31;0] = FIFOCOUT [ 31 : 0 ] ; 
fifoRdEnable = 'LOW; 
cOEenable = 'LOW; 

end 

end 



//* Output address info from FIFOs to diary 
Sfdisplay { f ileHandle , "Address = %h\t%h\t%h 
Cdata) ; 



end 



file 
, Adata, 



Bdata, 



wait { ( f if oAEmpty_N == 'HIGH) aa { f if oBEmpty_N == 'HIGH) ScSc 
(fifoCEmpty_N == 'HIGH)) 

begin 

//* Read FIFO A -- should be control from CPU A 
(3(negedge READCLK) 
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begin 

#5; 

fifoRdEnable = 'HIGH; 
aOEenable = 'HIGH; 

@(posedge READCLK) 
begin 
#10; 

Adata[31:0] = FIFOAOUT [ 31 : 0 ] ; 
fifoRdEnable = 'LOW; 
aOEenable = 'LOW; 

end 

end 

//* Read FIFO B -- should be control from CPU B 
@ (negedge READCLK) 
begin 
#5; 

fifoRdEnable = 'HIGH; 
bOEenable = 'HIGH; 

@(posedge READCLK) 
begin 
# 10 ; 

Bdata[31:0] = FIFOBOUT [ 31 : 0 ] ; 
fifoRdEnable = 'LOW; 
bOEenable = 'LOW; 

end 

end 

//* Read FIFO C -- should be control from CPU C 
@ (negedge READCLK) 
begin 
#5; 

fifoRdEnable = 'HIGH; 
cOEenable = 'HIGH; 

@(posedge READCLK) 
begin 
# 10 ; 

Cdata[31:0] = FIFOCOUT [ 31 : 0 ] ; 
fifoRdEnable = 'LOW; 
cOEenable = 'LOW; 

end 

end 

//* Output control info from FIFOs to diary file 
$fdisplay ( f ileHandle, "Control = %h\t%h\t%h", Adata, Bdata, 
Cdata) ; 

//* Save CONTROL data for displaying control status at end 

//* of reading DATA data from FIFO 

saveAdata = Adata; 

saveBdata = Bdata; 

saveCdata = Cdata; 

end 

wait ( ( f if oAEmpty_N == 'HIGH) && ( f if oBEmpty_N == 'HIGH) ScSc 
( f if oCEmpty_N == 'HIGH)) 

begin 
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//* Read FIFO A -- should be data to/ from CPU A 
@{negedge READCLK) 
begin 
#5; 

fifoRdEnable = 'HIGH; 
aOEenable = 'HIGH; 

@{posedge READCLK) 
begin 
# 10 ; 

Adata[31:0] = FIFOAOUT[31:0]; 
fifoRdEnable = 'LOW; 
aOEenable = 'LOW; 

end 

end 

//* Read FIFO B should be data to/ from CPU B 
@{negedge READCLK) 
begin 
#5; 

fifoRdEnable = 'HIGH; 
bOEenable = 'HIGH; 

@ (posedge READCLK) 
begin 
# 10 ; 

Bdata[31:0] = FIFOBOUT [ 3 1 : 0 ] ; 
fifoRdEnable = 'LOW; 
bOEenable = 'LOW; 

end 

end 

//* Read FIFO C -- should be data to/ from CPU C 
@ (negedge READCLK) 
begin 
#5; 

fifoRdEnable = 'HIGH; 
cOEenable = 'HIGH; 

@ (posedge READCLK) 
begin 
# 10 ; 

Cdata[31:0] = FIFOCOUT [31 ; 0] ; 
fifoRdEnable = 'LOW; 
cOEenable = 'LOW; 

end 

end 

//* Output data info from FIFOs to diary file 
$fdisplay (fileHandle, "Data = %h\t%h\t%h" , Adata, Bdata, 
Cdata) ; 

case (saveAdata [4:2] ) 

3'bOlO: 

$fdisplay { f ileHandle, "A Control = Burst Read Word %d" , 
saveAdata [1:0]); 

3'bllO: 

$f display { fileHandle, "A Control = Read" ) ; 

3'blOl: 

$fdisplay (fileHandle, "A Control = Write"); 
default : 



154 



Sfdisplay (f ileHandle, "A Control = Illegal Bus 

Transaction " ) ; 

endcase 



case { saveBdata [4:2] ) 

3 'bOlO: 

$fdisplay {fileHandle, "B Control 
saveBdata [1:0]); 

3 'bllO: 

$fdisplay (fileHandle, "B Control 
3 'blOl: 

$f display { fileHandle , "B Control 
default : 

$fdisplay {fileHandle, "B Control 

Transaction " ) ; 

endcase 



Burst Read Word %d 



Read" ) ; 
Write" ) ; 
Illegal Bus 



case (saveCdata [4:2] ) 

3'bOlO: 

$fdisplay (f ileHandle, "C Control 
saveCdata [1:0]); 

3 'bllO: 

$fdisplay ( f ileHandle, "C Control 
3 'blOl: 

$fdisplay ( f ileHandle, "C Control 
default : 

$fdisplay {fileHandle, "C Control 

Transaction" ) ; 

endcase 



Burst Read Word %d 



Read" ) ; 
Write" ) ; 
Illegal Bus 



$f display ( f ileHandle, 



end 



end 

endinodule //* end module interface 
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APPENDIX D. CADENCE SCRIPT CONTROL LANGUAGE FILES 

This appendix contains two SCL files which were used to 
generate the simulation results obtained in Chapter V. 



A. NORMAL (ERROR FREE) SCL FILE 



//* File: normal. scl 

/ /'^ 

//* Description: Cadence Logic Workbench Opensim Script Control 

//* Language (SCL) file. This file executes several bus cycles for 

//* the TMR Testbed schematic. All of the bus cycles in this file 

//* should be error free. 

//* 

//* Author: John C. Payne, Jr. 

//* Date: 11/30/98 



//* Definitions for transaction codes 

//* (same as in verilog file for R3081 module) 

NONE = 0 

READ_BYTE = 1 

READ_WORD = 2 

READ_BURST = 3 

WRITE_BYTE = 4 

WRITE^WORD = 5 



//* Initialize board interface lines 
DEPOSIT ' PWRRESET* ' , 0 

DEPOSIT 'TESTEN1*^ 0 



DEPOSIT 'FORCE_A' , 
DEPOSIT 'FORCE^B', 
DEPOSIT 'FORCE_C' , 
DEPOSIT 'USEFIFO', 
DEPOSIT 'PULL_UP', 
DEPOSIT 'GND', 0 



0 

0 

0 

1 

1 



DEPOSIT 'A_TRANS', (NONE) 
DEPOSIT 'B_TRANS', (NONE) 
DEPOSIT 'C_TRANS', (NONE) 



//* These initializations are necessary to prevent timing violations 
//* in the simulation 
DEPOSIT 'RAMCS*', 1 

EPROMCS*', 1 
INTCS* ' , 1 



DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 



' WREN_A* ' 
'WREN_B* ' 
'WREN_C* ' 
'WREN_D*‘ 
'RDEN* ' , 
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//* Hold board reset and release 
sim 1000ns 

DEPOSIT ' PWRRESET* ' , 1 

//* Advance simulation clock during initial burst read from EPROM 
//* address IFCOOOOO which is initiated by the R3081 modules 
while (#'VOTRD*' == 1) 
sim 25ns 

while (#'VOTRD*' == 0) 
sim 25ns 

sim 50ns 



j |•kir•k•k-k^k'k•k'k^ki(^k'k^k•k-kif'k^k^kic^kif^kie•k•k^k^k^kie^k^k^k•k•k^^k'k'k^k•k 

//* Test Burst Read Bus Cycle from EPROM 

y^y'itr**************************************** 

DEPOSIT 'A_TRANS\ (READ_BURST) 

DEPOSIT ' B_TRANS ' , (READ_BURST) 

DEPOSIT 'C_TRANS', (READ_BURST) 

//* Burst Read next EPROM Address 
DEPOSIT 'A^ADDR', $xlFC00010 
DEPOSIT 'B_ADDR', $xlFC00010 
DEPOSIT 'C_ADDR', $xlFC00010 

//* Advance simulation clock 
while (#'VOTRD*' == 1) 
sim 25ns 

while (#'VOTRD*' == 0) 
sim 25ns 



//* Advance sim clock to ensure previous cycle completes 



DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 



^ A_TRANS ' 
' B_TRANS ' 
' C_TRANS ' 
' A_ADDR ' , 
'B_ADDR' , 
'C ADDR' , 



(NONE) 

(NONE) 

(NONE) 

$XZZ22ZZZZ 

$xzzzzzzzz 

$xzzzzzzzz 



sim 50ns 



j I'k'k'k'k'k'k'k'k’k'k'k’k'k'k'k'k’k'k’k'k'k'k'k'k'k'k'k’k’k'k'k'kir'k'k'k'kir’k'k’k 

1 1 Test Write Bus Cycle 



DEPOSIT 'A_TRANS', 
DEPOSIT 'B_TRANS', 
DEPOSIT 'C_TRANS', 



(WRITE_WORD) 

(WRITE_WORD) 

(WRITE_WORD) 



//* Write to Lower RAM Boundary 
DEPOSIT 'A_ADDR', $x00000000 
DEPOSIT 'B_ADDR', SxOOOOOOOO 
DEPOSIT 'C_ADDR', $x00000000 



DEPOSIT 'A_DATA' 
DEPOSIT 'B DATA' 



Sxllllllll 

Sxllllllll 
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DEPOSIT 'C_DATA', 

//* Advance simulation clock 
while (#'VOTWR*' == 1) 
sim 25ns 

while (#'VOTWR*' == 0) 
sim 25ns 



//* Advance sim clock to ensure previous cycle completes 



DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 



'A_TRANS^ (NONE) 
'B_TRANS', (NONE) 
'C_TRANS\ (NONE) 
'A_ADDR' , Sxzzzzzzzz 
'B_ADDR' , Sxzzzzzzzz 
'C_ADDR' , Sxzzzzzzzz 
'A_DATA' , Sxzzzzzzzz 
'B_DATA' , Sxzzzzzzzz 
'C_DATA', Sxzzzzzzzz 



sim 50ns 



//* Test Write Bus Cycle 



DEPOSIT 'A_TRANS^, (WRITE_WORD) 
DEPOSIT 'B_TRANS^ (WRITE_WORD) 
DEPOSIT ^C_TRANS', (WRITE_WORD) 

//* Write to RAM 
DEPOSIT 'A_ADDR', Sx00000004 
DEPOSIT 'B_ADDR', Sx00000004 
DEPOSIT 'C_ADDR', Sx00000004 

DEPOSIT ^A_DATA', Sx22222222 
DEPOSIT ^B_DATA^, Sx22222222 
DEPOSIT 'C_DATA', Sx22222222 

while (#'VOTWR*' == 1) 
sim 25ns 

while (#'VOTWR*' == 0) 
sim 25ns 



//* Advance sim clock to ensure previous cycle completes 



DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 



' A_TRANS ' 
' B_TRANS ' 
' C_TRANS ' 
' A_ADDR 
' B_ADDR 
' C_ADDR 
' A_DATA 
' B_DATA 
' C_DATA 



. (NONE) 

^ (NONE) 
(NONE) 
Sxzzzzzzzz 
Sxzzzzzzzz 
Sxzzzzzzzz 
Sxzzzzzzzz 
Sxzzzzzzzz 
Sxzzzzzzzz 



sim 50ns 
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•k tr -k 



k k k k 



k k * k 



! Ikkkkkkkk-K-Kkk-ttkfc-mkkkkkkkkk 

//* Test Write Bus Cycle 

! ^k*-k***k*’kk*-k*-k-k*kkk-k-k*-kkk 

DEPOSIT 'A_TRANS^ (WRITE_WORD) 

DEPOSIT 'B_TRANS^ (WRITE_WORD) 

DEPOSIT 'C_TRANS^ (WRITE_WORD) 

//■^ Write to RAM 
DEPOSIT 'A_ADDR', $x00000008 
DEPOSIT 'B_ADDR', $x00000008 
DEPOSIT 'C_ADDR', $x00000008 

DEPOSIT 'A_DATA', $x33333333 
DEPOSIT 'B_DATA^ $x33333333 
DEPOSIT 'C_DATA^ $x33333333 

//* Advance simulation clock 
while (#'VOTWR*^ == 1) 
sim 25ns 

while (#'VOTWR*' == 0) 
sim 25ns 

//* Advance sim clock to ensure previous cycle completes 
DEPOSIT 'A_TRANS', (NONE) 

DEPOSIT 'B_TRANS', (NONE) 

DEPOSIT 'C_TRANS^ (NONE) 

DEPOSIT 'A_ADDR\ $xzzzzzzzz 
DEPOSIT 'B_ADDR', $xzzzzzzzz 
DEPOSIT 'C_ADDR', $xzzzzzzzz 
DEPOSIT 'A_DATA', $xzzzzzzzz 
DEPOSIT 'B_DATA', $xzzzzzzzz 
DEPOSIT 'C_DATA', $xzzzzzzzz 

sim 50ns 



^^•k*k-k-kk*k-k*-k*'kkk*kkk’kk**k*kk*****kk*k-kkkkk 

//* Test Write Bus Cycle 

j |•k•k•k•k•k•k•kk•k•k'k•k'kkkkk^k•k'k•k’kk•kkk'k•kkk•kkkk'k•k^kk•kkk 



DEPOSIT 'A_TRANS', (WRITE_WORD) 
DEPOSIT 'B_TRANS', (WRITE_WORD) 
DEPOSIT 'C_TRANS', (WRITE_WORD) 



//* Write to RAM 
DEPOSIT 'A_ADDR', 
DEPOSIT 'B_ADDR', 
DEPOSIT 'C_ADDR', 



$x0000000C 

$x0000000C 

$x0000000C 



DEPOSIT 'A_DATA', $x44444444 
DEPOSIT 'B_DATA', $x44444444 
DEPOSIT 'C_DATA', $x44444444 



//* Advance simulation clock 
while (#'VOTWR*' == 1) 
sim 25ns 

while (#'VOTWR»' == 0) 
sim 25ns 
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//* Advance sim clock to ensure previous cycle completes 
DEPOSIT 'A_TRANS', (NONE) 

DEPOSIT 'B_TRANS', (NONE) 

DEPOSIT 'C_TRANS', (NONE) 

DEPOSIT 'A_ADDR', $X222222Z2 
DEPOSIT 'B_ADDR', $X22222Z22 
DEPOSIT 'C_ADDR', $X22222222 
DEPOSIT 'A_DATA\ $X22222222 
DEPOSIT 'B_DATA', $X2222222Z 
DEPOSIT 'C_DATA', $X22222222 

sim 50ns 



//* Test Read Bus Cycle 

DEPOSIT 'A^TRANS', (READ_WORD) 
DEPOSIT 'B.TRANS', (READ^WORD) 
DEPOSIT 'C_TRANS', (READ_WORD) 

//* Read Lower RAM Boundary 
DEPOSIT 'A_ADDR', $x00000000 
DEPOSIT 'B__ADDR^ $x00000000 
DEPOSIT 'C_ADDR', $x00000000 



//* Advance simulation clock 
while (#'V0TRD*' == 1) 
sim 25ns 

while (#'VOTRD*' == 0) 
sim 25ns 

//* Advance sim clock to ensure previous cycle completes 
DEPOSIT 'A_TRANS', (NONE) 

DEPOSIT ' B_TRANS ' , (NONE) 

DEPOSIT 'C.TRANS^ (NONE) 

DEPOSIT 'A_ADDR' , $X22222222 
DEPOSIT 'B_ADDR', $X22222Z22 
DEPOSIT 'C^ADDR', $X22222222 

sim 50ns 



j I'k'k'k'k'k'k'k'k'k'k'k'k'k'k’k'k'k'k'k'k'k'k'k'k'k'k'k'k'k’k'k'k'k'k'k'k'k'k'k'k'k 

//* Test Burst Read Bus Cycle from RAM 



DEPOSIT 'A_TRANS', 
DEPOSIT 'B_TRANS', 
DEPOSIT 'C_TRANS', 



(READ.BURST) 

(READ_BURST) 

(READ_BURST) 



//* Burst Read from RAM 
DEPOSIT 'A_ADDR^ $x0000 
DEPOSIT 'B_ADDR', $x0000 
DEPOSIT 'C_ADDR', $x0000 



0000 

0000 

0000 
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//* Advance simulation clock 
while (#'VOTRD*' == 1) 
sim 25ns 

while (#'VOTRD"^' == 0) 
sim 25ns 

DEPOSIT 'A_TRANS^ (NONE) 

DEPOSIT ' B^TRANS ' , (NONE) 

DEPOSIT 'C^TRANS', (NONE) 

DEPOSIT 'A_ADDR', $X22Z22222 
DEPOSIT 'B_ADDR', $X22222222 
DEPOSIT 'C_ADDR', $X22222Z22 

//* Advance sim clock to ensure previous cycle completes and FIFO is 
//* emptied 
sim 150ns 



B. ERROR SCL FILE 



//* File: errors . scl 

//* 

//* Description: Cadence Logic Workbench Opensim Script Control 

//* Language (SCL) file. This file executes several bus cycles for 
J!'^ the TMR Testbed schematic. Several of the bus cycles in this 
//’‘^ file should contain errors. 

//* 

//* Author: John C. Payne, Jr. 

//^ Date: 11/30/98 



//* Definitions for transaction codes 

//* (same as in verilog file for R3081 module) 

NONE = 0 

READ_BYTE = 1 

READ_WORD = 2 

READ_BURST = 3 

WRITE_BYTE = 4 

WRITE_WORD = 5 



//* Initialize board interface lines 
DEPOSIT ' PWRRESET* ' , 0 
DEPOSIT 'TESTENl*', 0 



DEPOSIT ' FORCE_A ' , 
DEPOSIT 'FORCE_B', 
DEPOSIT 'FORCE_C', 
DEPOSIT 'USEFIFO', 
DEPOSIT 'PULL_UP', 
DEPOSIT 'GND', 0 



0 

0 

0 

1 

1 



DEPOSIT 'A_TRANS', (NONE) 
DEPOSIT 'B_TRANS', (NONE) 
DEPOSIT 'C_TRANS', (NONE) 



//* These initializations are necessary to prevent timing violations 
//* in the simulation 
DEPOSIT 'RAMCS*', 1 
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DEPOSIT 'EPROMCS*', 1 
DEPOSIT 'INTCS*', 1 
DEPOSIT 'WREN_A*', 1 
DEPOSIT 'WREN_B*', 1 
DEPOSIT 'WREN_C*', 1 
DEPOSIT 'WREN_D*', 1 
DEPOSIT 'RDEN*', 1 

//* Hold board reset and release 
sim 1000ns 

DEPOSIT 'PWRRESET*', 1 

//* Advance simulation clock during initial burst read from EPROM 
//* address IFCOOOOO which is initiated by the R3081 modules 
while (#'VOTRD*' == 1) 
sim 25ns 

while (#'VOTRD*' == 0) 
sim 25ns 

sim 50ns 



//* Test Write Bus Cycle 

//* - with single error in address inputs 



DEPOSIT 'A_TRANS', (WRITE_WORD) 
DEPOSIT 'B_TRANS^ (WRITE_WORD) 
DEPOSIT 'C_TRANS^ (WRITE_WORD) 



//* Write to RAM 
DEPOSIT 'A_ADDR^ 
DEPOSIT 'B_ADDR', 
DEPOSIT 'C_ADDR', 



$x00000100 

$x00000000 

$x00000000 



DEPOSIT 'A_DATA', $xllllllll 
DEPOSIT 'B_DATA^ $xllllllll 
DEPOSIT 'C_DATA^ $xllllllll 



//* Advance simulation clock 
while (#'VOTWR*^ == 1) 
sim 25ns 

while (#'VOTWR*^ == 0) 
sim 25ns 



//* Advance sim clock to ensure previous cycle and the interrupt 
//* service routine which is initiated by the R3081 complete 



DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 



^ A_TRANS ' 
' B_TRANS ' 
' C_TRAMS ' 
' A_ADDR ' , 
' B_ADDR ' , 
' C_ADDR ' , 
' A_DATA ' , 
^ B_DATA ' , 
' C_DATA ' . 



, (NONE) 

, (NONE) 

, (NONE) 
$xzzzzzzzz 
$xzzzzzzzz 
$xzzzzzzzz 
$xzzzzzzzz 
$xzzzzzzzz 
$xzzzzzzzz 



sim 3700ns 
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//* Test Write Bus Cycle 
//* 

//* 

//** 



rrA'***w*Tr*i 



- with mu 


Itiple errors i 


inputs 




★ ★★■»★★★★★★★★•*■•*★ 


' 'A_TRANS 


' , (WRITE_WORD) 


'B_TRANS 


' , (WRITE_WORD) 


‘ 'C_TRANS 


' , (WRITE_WORD) 


te to RAM 


' 'A_ADDR' 


, $x00000004 


'B_ADDR' 


, $x01000004 


'C_ADDR' 


, $x00000005 


'A_DATA' 


, $x22222222 


'B_DATA' 


, $x22222222 


'C_DATA' 


, $x22222222 



//* Advance simulation clock 
while (#'VOTWR*' == 1) 
sim 25ns 

while (#'VOTWR*' == 0) 
sim 25ns 



//* Advance sim clock to ensure previous cycle and the interrupt 
//* service routine which is initiated by the R3081 complete 



DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 



' A_TRANS ' 
' B_TRANS ' 
' C^TRANS ' 
' A_ADDR ' , 
' B_ADDR ' , 
' C_ADDR ' , 
'A_DATA' , 
'B_DATA' , 
' C DATA ' , 



, (NONE) 

. (NONE) 

. (NONE) 
$xzzzzzzzz 
Sxzzzzzzzz 
$xzzzzzzzz 
$xzzzzzzzz 
$xzzzzzzzz 
Sxzzzzzzzz 



sim 3700ns 



j 


★★★★★★★★★ 




//* Test 


Write Bus Cycle 


//* 


with single error in data inputs 


j y****** 






DEPOSIT 


' A_TRANS ' 


, (WRITE_WORD) 


DEPOSIT 


' B_TRANS ' 


, (WRITE_WORD) 


DEPOSIT 


' C_TRANS ' 


, (WRITE_WORD) 


//* Write to RAM 




DEPOSIT 


' A_ADDR ' , 


$x00000008 


DEPOSIT 


'B_ADDR' , 


$x00000008 


DEPOSIT 


' C_ADDR ' , 


$x00000008 


DEPOSIT 


'A_DATA' , 


$x33333333 


DEPOSIT 


' B_DATA ' , 


$x33333333 


DEPOSIT 


'C_DATA' , 


$x33333337 
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//* Advance simulation clock 
while (#'VOTWR*' == 1) 
sim 25ns 

while {#'VOTWR*^ == 0) 
sim 25ns 



//* Advance sim clock to ensure previous cycle and the interrupt 
//* service routine which is initiated by the R3081 complete 



DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 



' A_TRANS ' 
' B.TRANS ' 
' C_TRANS ' 
' A_ADDR ' , 
' B__ADDR ' , 
' C_ADDR ' , 
' A_DATA ' , 
' B_DATA ' , 
' C DATA ' , 



(NONE) 

(NONE) 

(NONE) 

$xzzzzzzzz 

$xzzzzzzzz 

$xzzzzzzzz 

$xzzzzzzzz 

$xzzzzzzzz 

$xzzzzzzzz 



sim 3700ns 



! y**********r*r******-*r*****r*r*r*r*****r*r*****r*r**** 

//* Test Write Bus Cycle 

//* - with multiple errors in data inputs 



DEPOSIT 'A__TRANS', (WRITE_WORD) 
DEPOSIT ' B_TRANS ' . (WRITE^WORD) 
DEPOSIT ' C__TRANS ' . (WRITE_WORD) 



//* Write to RAM 
DEPOSIT 'A_ADDR', 
DEPOSIT 'B_ADDR', 
DEPOSIT 'C_ADDR', 



SxOOOOOOOC 

SxOOOOOOOC 

$x0000000C 



DEPOSIT 

DEPOSIT 

DEPOSIT 



'A_DATA' , $xF4444444 
'B_DATA' , $x44A44444 
'C_DATA' , $x44444447 



//* Advance simulation clock 
while (#'VOTWR*' == 1) 
sim 25ns 

while (#'VOTWR*' == 0) 
sim 25ns 



//* Advance sim clock to ensure previous cycle and the interrupt 
//* service routine which is initiated by the R3081 complete 



DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 



' A_TRANS ^ 
' B_TRANS ' 
' C_TRANS - 
'A_ADDR' , 
'B_ADDR^ , 
' C_ADDR ' , 
' A_DATA ' , 
' B_DATA ' , 
' C DATA ' , 



(NONE) 

(NONE) 

(NONE) 

$xzzzzzzzz 

$xzzzzzzzz 

Sxzzzzzzzz 

$xzzzzzzzz 

$xzzzzzzzz 

Sxzzzzzzzz 



sim 3700ns 
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/ /^ Test Burst Read Bus Cycle 

DEPOSIT 'A_TRANS', (READ_BURST) 
DEPOSIT 'B_TRANS', (READ_BURST) 
DEPOSIT 'C_TRANS', (READ_BURST) 

//* Burst Read from RAM 
DEPOSIT 'A_ADDR', $x00000000 
DEPOSIT 'B_ADDR', $x00000000 
DEPOSIT 'C_ADDR', SxOOOOOOOO 

//* Advance simulation clock 
while (#'VOTRD*' == 1) 
sim 25ns 

while (#'VOTRD*' == 0) 
sim 25ns 



//* Advance sim clock to ensure previous cycle completes 



DEPOSIT 


' A_TRANS ' . 


(NONE) 


DEPOSIT 


' B_TRANS ' , 


(NONE) 


DEPOSIT 


' C^TRANS ' . 


(NONE) 


DEPOSIT 


^ A_ADDR ' , 


$X22222222 


DEPOSIT 


^ B^ADDR ' , 


$X22222222 


DEPOSIT 


' C_ADDR ' , 


$X22222222 


DEPOSIT 


' A_DATA ^ , 


$X22222222 


DEPOSIT 


' B_DATA ' , 


$X22222222 


DEPOSIT 


'C^DATA' . 


$X22222222 


sim 50ns 






! 1 ***** * 


*********************** 


//* Test 


Write Bus 


Cycle 


//* 


with error in control 


! !****** 


★★★★★★★★★★★★★★★★★★★★★★★ 


DEPOSIT 


'A_TRANS' , 


(WRITE_WORD) 


DEPOSIT 


' B_TRANS ' , 


(READ^BURST) 


DEPOSIT 


' C_TRANS ' , 


(WRITE_WORD) 


//* Write to RAM 




DEPOSIT 


^ A_ADDR ' , 


$x00004000 


DEPOSIT 


'B_hDDR' , 


$x00004000 


DEPOSIT 


'C_ADDR' , 


$x00004000 


DEPOSIT 


' A_DATA ' , 


$x78787878 


DEPOSIT 


' B^DATA ' , 


$x78787878 


DEPOSIT 


' C_DATA ' , 


$x78787878 


//* Advance simulation clock 


while (# 


'VOTWR*' = 


= 1) 


sim 25ns 




while (# 


'VOTWR*' = 


= 0) 



sim 25ns 
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//* Advance sim clock to ensure previous cycle and the interrupt 
//* service routine which is initiated by the R3081 complete 



DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 



' A_TRANS ' 
' B_TRANS ' 
' C^TRANS ' 
'A_ADDR' . 
' B_ADDR ' , 
' C_ADDR ' , 
' A_DATA ' , 
' B_DATA ' , 
' C_DATA ' , 



(NONE) 

(NONE) 

(NONE) 

$X22222222 

$X22222222 

$X22222222 

$X22222222 

$X22222222 

$X22222222 



sim 3700ns 



//* Test Read Bus Cycle 

DEPOS IT ' A^TRAJMS ' , ( READ_WORD ) 

DEPOSIT 'B_TRAUS^, (READ_WORD) 
DEPOSIT X_TRANS^ (READ_WORD) 

//* Burst Read from RAM 
DEPOSIT 'A_ADDR', $x00004000 
DEPOSIT 'B_ADDR', $x00004000 
DEPOSIT X_ADDR^ $x00004000 

//* Advance simulation clock 
while (#'VOTRD-*^' == 1) 
sim 25ns 

while (#'VOTRD*' == 0) 
sim 25ns 



DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 

DEPOSIT 



'A^TRAMS^ (NONE) 
^B_TRANS^ (NONE) 
X_TRANS', (NONE) 

'A_ADDR' , $X22222222 
'B_ADDR' , $X22222222 
'C_ADDR' , $X22222222 
' A_DATA' , $X22222222 
'B_DATA' , $X22222222 
X__DATA' , $X22222222 



//* Advance sim clock to ensure previous cycle completes and FIFO is 
//* emptied 
sim 150ns 
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